An automatic system replacing human routing

Discussions
1

Here it is. During vibe coding, the human acts as the router, manually telling an LLM agent at each step what to do next. Now I want to replace that human router with an automatic system. The core problem: if I give the agent my full detailed workflow upfront — around eight thousand lines — it gets overloaded, hallucinates, and can’t obey everything because most branches are irrelevant junk. But if I give too little, the agent lacks the blueprint and may take the wrong path. My idea is just-in-time context loading: provide instructions only when the agent reaches the step that needs them, like handing over a database key only at the moment it’s required. The open question is how to balance that — what to give, when, and how much.

5

Cursor has a built-in way to do just-in-time loading: skills. The agent is shown your available skills and decides which one is relevant from its description, and anything you put in a skill’s references/ folder is loaded on demand instead of upfront.

How I’d split an 8k-line workflow:

  1. Keep a short always-on core (what the steps are, in what order, and which skill covers each) in an AGENTS.md or an alwaysApply rule. The rules docs suggest staying under 500 lines and splitting big rules into smaller composable ones.
  2. Turn each branch or step into its own skill with a specific description of when it applies (“use when migrating the database schema”), and move the long detail into that skill’s references/ files.
  3. If a step maps to certain files, add paths globs to the skill (or globs to a rule) so it only surfaces when the agent is reading or editing matching files.
  4. For steps that should never fire on their own, set disable-model-invocation: true and call them with /skill-name when you get there.

The catch: the agent still picks skills by description, so vague descriptions are the main way this goes wrong. Write them like triggers, not summaries.

How skills load, plus the references/ and paths setup: Agent Skills | Cursor Docs
Rule types and size guidance: Rules | Cursor Docs

7

No. Skill is also the something that you told the LLM too early or too much, and LLM think that maybe I need that then prefetch the skill too early. “Just-in-time” and what the should tell skill.

Let’s say, you want to tighten the screw, and you open the tool box(skill) and found there are kind of tools: hammer, pliers , electric drill, screwdriver etc,. what you want is only screwdriver, all other tools are unless(but LLM fetched into context window).

Of cause you can split the the tool box into hammer box, which only hammer in it, pilers box, electric drill box, screwdriver box etc,. it’s like that you split the skill into multi & sub skill, and you must tell the LLM some extra information: usage of each tool and when to use.

“The catch: the agent still picks skills by description, so vague descriptions are the main way this goes wrong. Write them like triggers, not summaries.”

I know it, write them like triggers, not summaries, but my point is: anything write down but not used is junk info. LLM still read the extra junk information of trigger when use other tools.

When human is the router, human won’t tell the other tools’ usage or any trigger, right? You won’t give the prompt like “there is screwdriver, when you want to screw, there is hummer, when you want to rive in a nail, and there is pliers, when you want to cut the wire short …”, you just say “there is screwdriver, when you want to screw”, cut all other unless info.

Be clearly, my question is: there a system like human: DO NOT tell LLM where the other tools or usage of them but only just give screwdriver to LLM , “JUST-IN-TIME” & “JUST-IN-NEED”.

8

Hey, you’re right: within a single session, skills don’t provide true “just-in-need” behavior. The model sees the descriptions of all skills and decides on its own what to load. If you need the model to know nothing about the other tools at all, the router has to live outside the model, meaning in your code.

You can do this with the Cursor SDK TypeScript or Python. Your script controls the agent and acts like a “human router”:

  1. The workflow lives in code, not in the prompt.
    The 8000 lines stay with the orchestrator as a state machine or step graph. They are not sent to the agent.

  2. At each step, send only that step’s instruction.
    With agent.send(), you give the agent only “here’s a screwdriver, tighten the screw.” It doesn’t know about the hammer or pliers.

  3. The code decides transitions, not the LLM.
    Have the agent finish each step with a structured status, for example JSON with the result, or check the artifacts yourself: tests passed, file created, exit code. Based on that signal, your code picks the next branch. That way the model doesn’t “prefetch” extra things, because there’s nothing extra to prefetch.

  4. You can literally expose only the needed tool.
    In the Python SDK, AgentOptions has tools and disallowed_tools for local agents. You can configure the tool set per step.

  5. Keep context clean between steps.
    If the branches are very different, create a new agent with Agent.create() for each step or group of steps, and pass only a short handoff from the previous one instead of the full history.

The tradeoff is that the “where to go next” part becomes deterministic, and you’ll need to describe it in code. For places where you can’t pick a branch from the signal alone, you can add a separate short classifier call. Give it only the list of options for that fork. It doesn’t need the whole workflow.

Docs:

If you share how the branches in your workflow are set up, like how many branches there are and what signals decide the path, I can help suggest which parts are better moved into code and which parts can stay with the model.

9

Yes. Something like that using general agent like cursor to create another task flow agent, also UI compnonent made.

And I just found a simple way to solve mix up with grokbot, each grokbot could be a tool communicate with cursor agent via a2a protocol.

I’ll share more info if it works.

10

Sounds like a workable plan. It’ll be interesting to see how it turns out.

One thing that’s worth thinking through early: if you connect all Grok Bots to one Cursor agent as a set of tools, the agent will see the descriptions of all those tools in its context. That’s the same situation as with skills, just in a different wrapper. If you want true just-in-need behavior, it’s better to have the orchestrator choose the next bot or tool. That way, at each step, the agent only knows about the one tool it needs right then. You can do this through the SDK if you pass a separate set of tools for each step.

A couple of practical notes:

Let me know how it goes. I’m especially curious how you’ll handle transitions at branch points where one signal isn’t enough to choose the path.