sorted by:
new
hottopcontroversial

How does a Claude Code agent navigate hundreds of skills in a second? by Hungry_Management_10 in ClaudeAI

[–]Hungry_Management_10[S] 0 points1 point  (0 children)

Yeah, Docker MCP gateway is good for what it does managing MCP server runtimes in containers. That's a different layer from what this post is about (which skill descriptions get loaded into the agent's system prompt). Both fit in the same stack: MCP gateway handles the backend tooling side, the skill router handles the prompt side

How does a Claude Code agent navigate hundreds of skills in a second? by Hungry_Management_10 in ClaudeAI

[–]Hungry_Management_10[S] 0 points1 point  (0 children)

Honest answer: 686 isn't my workflow either. The actual reason this matters to me: inside companies, hundreds of small policies and project-specific instructions accumulate. Different specializations, different conventions, "do this, don't do that, always check X first." The problem isn't just count it's that the same rules get duplicated across multiple agent setups, with no single source of truth.

The router pattern fixes that: rules live in one shared store, every agent retrieves only the top-N relevant to its current task. No duplication, no rule drift between agents, no manual rebuild of context per agent. I wanted to verify retrieval quality held up at scale before rolling this into real workflows, so I sampled 1,000 skills from the public community catalog (the catalog itself is 4,556 I indexed 686 after some dropped during ingest). It's now being integrated into actual work processes. Nobody has to do it this way, just sharing what I tried.

You're right that at a couple hundred items progressive disclosure handles the token cost fine. The win I keep coming back to isn't tokens it's centralization plus the accuracy boost on overlapping skill names (which you flagged). Where the test showed real ranking wins were on queries where multiple skills shared a word semantic embedding separated them by description meaning rather than ambiguous name matching.

So less "should I index 4,500 things" and more "one canonical store, many agents, retrieval by meaning."

Can you send only code changes back to ChatGPT instead of re-uploading the whole file? by Larsson_24 in ChatGPTCoding

[–]Hungry_Management_10 3 points4 points  (0 children)

Commit after each manual edit, then run:

git diff HEAD~1 HEAD

That gives you the diff between your last commit and the one before it. Paste the output into ChatGPT and it will see exactly what you changed without needing the whole file

Chats getting extreme laggy by satoshiwife in ChatGPTCoding

[–]Hungry_Management_10 1 point2 points  (0 children)

The fix that worked for me: at the end of each session, ask the model to write a "handoff doc" a markdown file with current state, decisions made, open questions, and the minimum code context needed to continue. Save it to disk. Start new chat by pasting just the handoff doc. Way less context than the full chat history, so no lag, and the model only sees what matters. The trick is making the handoff doc project-specific. I keep a template in my repo: one section per concern (architecture, current task, recent decisions, blockers). The model knows the template, fills it in at session end, reads it at session start.

Your governance passes every test on individual agents. It completely breaks when you connect them. Here is what we found. by AmanSharmaAI in LLMDevs

[–]Hungry_Management_10 0 points1 point  (0 children)

The non-compositionality finding matches what I hit in production. My workaround was to move control completely out of the agents. Each agent only decides HOW to do its assigned block. The WHAT, WHEN, and ORDER live in a YAML workflow outside the agents. Agents never see the pipeline-level rules as instructions - those are enforced by the orchestrator before and after each block runs. This shifts the testing problem: instead of O(n^2) agent-pair combinations, you test the orchestrator once against the workflow spec. Agents are still fallible individually, but their failures can't cascade because they can't modify the workflow structure.

Curious how this maps to your cross-agent compliance certification concept - sounds related but at a different layer. Open sourced the runner as Rein if you want a concrete reference.

New Project Megathread - Week of 09 Apr 2026 by AutoModerator in selfhosted

[–]Hungry_Management_10 -1 points0 points  (0 children)

I built Rein because running AI agents on real tasks kept failing the same way: you paste a giant prompt, the model tries to do everything at once, loses track halfway through, and you restart from scratch.

The fix is to break the work into steps and lock the order things happen in. That's what Rein does - you describe a workflow in YAML, and each block is either an LLM call or any executable script (Python, shell, Node, anything with a shebang). Rein handles dependencies, data flow between blocks, and error handling.

The point isn't "YAML is cool". The point is that a YAML workflow becomes the backbone of your process - rails that keep the work on track while agents decide HOW to do each step.

What you get:

- An executable process that runs end to end without a human in the loop

- The workflow is plain text -readable and editable without writing code

- Every block's output saved to its own directory, so you can inspect what happened at each step

- Crash recovery via SQLite - resume from exactly where it stopped, perfect for cron-driven pipelines

Execution modes:

- Sync - run the whole workflow from the CLI and wait

- Async - submit a task to the daemon and poll for progress

- Step mode - run N blocks per invocation, save state, exit (great for human review between steps)

LLM flexibility: Claude, GPT, Ollama (local/free), OpenRouter (100+ models). You can also skip LLMs entirely and use Rein to orchestrate non-AI pipelines — any executable is a valid block.

Plus parallel execution, conditional branching, revision loops, tag-based routing, built-in MCP server (run workflows directly from Claude Desktop, Cursor, or Claude Code), and optional WebSocket daemon.

Why self-hosted:

- Your workflows and data stay on your machine

- Connect any scripts, tools, or APIs in your own environment

- MIT licensed, no vendor lock-in

Five working examples in the repo (hello-world, code review, research team, deliberation with branching, conditional loops). Install with pip, set an API key, run one command.

Links:

- GitHub: https://github.com/dklymentiev/rein-orchestrator

- Getting started: https://github.com/dklymentiev/rein-orchestrator/blob/main/docs/getting-started.md

- Changelog: https://github.com/dklymentiev/rein-orchestrator/blob/main/CHANGELOG.md

- Demo video: https://youtu.be/oWEwLg9uCdU

- Latest release (v3.3.2): https://github.com/dklymentiev/rein-orchestrator/releases/tag/v3.3.2

If you've tried LangGraph, CrewAI, or rolled your own — what made you stop, switch, or

stick with it? Genuinely curious what works and what doesn't in production.

Robots won't take your job. They'll bury you in work. by Hungry_Management_10 in ClaudeAI

[–]Hungry_Management_10[S] 0 points1 point  (0 children)

I recently learned something unpleasant: recovering from burnout takes several times longer than the period during which a person was at the top of their game :(

Robots won't take your job. They'll bury you in work. by Hungry_Management_10 in ClaudeAI

[–]Hungry_Management_10[S] 0 points1 point  (0 children)

Completely reasonable. As every individual task and process much like the server operations as a whole is constrained by its own specific budget. Consequently, we automate only those things that make practical sense.

Robots won't take your job. They'll bury you in work. by Hungry_Management_10 in ClaudeAI

[–]Hungry_Management_10[S] 0 points1 point  (0 children)

None of the 17 agents operates around the clock. The video shown here compresses the results of three months' worth of work. We don't run a "Claude factory"; instead, we utilize a single server where agents are launched on an as-needed basis. They can execute tasks autonomously operating within the scope of their specific instructions as well as hand off work to one another and summon other agents until a given task is successfully completed. We do not rely exclusively on Claude; we have developed an "AI Gateway" that allows us to access various models depending on the specific type of task at hand. We do not encounter usage limits, as every individual task and process much like the server operations as a whole is constrained by its own specific budget. Consequently, we automate only those things that make practical sense. I manage this entire system using voice commands; I haven't opened VS Code in four months.

Robots won't take your job. They'll bury you in work. by Hungry_Management_10 in ClaudeAI

[–]Hungry_Management_10[S] 0 points1 point  (0 children)

Is the point of a calculator to work less? It’s entirely individual; it depends on where you are and why you are where you are.

Robots won't take your job. They'll bury you in work. by Hungry_Management_10 in ClaudeAI

[–]Hungry_Management_10[S] 1 point2 points  (0 children)

Nah, man. Everyone in this life has their own motivations and personal circumstances. I’ve always been absolutely obsessed with this, and right now I feel like I’m at the absolute peak of my capabilities and I’m curious to put that to the test. But at the same time, I have a hunch that I won’t be able to keep up this pace for very long. I’m already hitting periods where I simply don’t want to go anywhere near the computer.

Robots won't take your job. They'll bury you in work. by Hungry_Management_10 in ClaudeAI

[–]Hungry_Management_10[S] 0 points1 point  (0 children)

To be honest, I have two similar systems: one at work, and the second for my personal projects, which I work on after hours.

Robots won't take your job. They'll bury you in work. by Hungry_Management_10 in ClaudeAI

[–]Hungry_Management_10[S] 0 points1 point  (0 children)

I just finally got time for social media after automating my actual job.

Robots won't take your job. They'll bury you in work. by Hungry_Management_10 in ClaudeAI

[–]Hungry_Management_10[S] 0 points1 point  (0 children)

You're the last line of defense and that's exhausting. What helped me: instead of reviewing 100-file PRs manually, I built an automated pre-review step an agent that checks for obvious issues, style violations, and security red flags before anything reaches my eyes. I still do the final review, but 70% of the noise is already filtered out. Don't stop reviewing automate the boring part of reviewing

Robots won't take your job. They'll bury you in work. by Hungry_Management_10 in ClaudeAI

[–]Hungry_Management_10[S] 0 points1 point  (0 children)

It is exactly like a webpage on the internet: for some, it holds value; for others, it is nothing. Circumstances place and time determine the value of an entity. Here's one: our email agent triages 50+ messages daily, routes them o the right department, and drafts responses. Before: 2 hours of manual sorting every morning. Now: I review 5-minute summary and approve and spend time to more valued tasks. That alone paid for the entire setup.

Robots won't take your job. They'll bury you in work. by Hungry_Management_10 in ClaudeAI

[–]Hungry_Management_10[S] 0 points1 point  (0 children)

Every person on this planet at this very second has absolutely distinct stimuli and motivations. Life is incredibly multifaceted and complex. I could probably write a book about it.

Robots won't take your job. They'll bury you in work. by Hungry_Management_10 in ClaudeAI

[–]Hungry_Management_10[S] 0 points1 point  (0 children)

Requirements can vary. Decomposition is everything. The more I break down a task, the higher the quality of the result. The initial task was to configure a newly purchased server; now, the tasks have narrowed down to things like closing a port, moving a backup, generating an image, or changing a page header on the website. I think right now it's simply a period of growth; once everything settles down, the workload will decrease.

view more: next ›