AI Agent Orchestration Framework: What It Actually Has to Solve

The second agent does not double the work, it changes it

One coding agent is manageable, and the loop stays visible. Read the output. Inspect the diff. Run the tests. Write the next prompt.

Then a second one starts.

Now both need the same view of the repository, and neither of them knows the first thing about what the other is doing. One reviews a branch while the other tests an older working tree. A command fails in one terminal. The second agent carries on with half the story. Nothing told it to stop. You alt-tab between windows, carrying results from one process to the other.

That is the actual change, and it is one of role rather than volume. You stop operating a tool and start routing messages between tools. You have become the message bus.

Why doesn't writing better prompts fix this?

Because the number of prompts was never the constraint.

The obvious reading is that two agents mean twice the prompting, so the answer must be sharper prompts or a tidier way to keep track of them. Sharper prompts do help each agent individually. They do nothing about the four questions that appeared when the second window opened. Who runs now? What context does it get? Where does its result go? What happens to the work waiting on that result?

Think of a shift handover. Two people work the same case and never overlap. Everything one of them learned has to travel through whoever stands in the middle. Better notes do not create the handover. That takes durable state, a transfer rule, and a visible signal when the transfer fails.

So the thing to look for is not a better prompt. The answers to those four questions need somewhere durable to live that is not your short-term memory.

AuricIDE makes the repository itself that place. Goals, tickets, requirements, test cases, dependencies and history sit in one record inside the project folder. Agents reach it through AuricIDE's MCP server. The agents and the app read the same rows. The Fleet view handles the attention half. It ranks error, then blocked on input, then stalled. You check that screen instead of every terminal.

What does an orchestrator actually have to control?

It has to control the harness, the shared context, the handoff and the failure. Those map onto the four questions above.

A harness definition. A harness wraps an external CLI so the system can start it and know when it ended. Every CLI has its own commands, input methods and exit behaviour, so the framework needs one stable way to describe them.

Shared context. Requirements and task history need a dependable home. Through MCP, the desktop app and the local processes read one set of records, which cuts down on copied prompts. Access still has to match.

A handoff rule. AuricIDE packages repeatable work as skills, where a skill is a prompt plus a provider, a model and a permission mode. Chains put skills in order. Each step receives a cleaned tail of the previous step's terminal output: ANSI codes stripped, interface chrome removed, repeats dropped, and AuricIDE caps what is left at 2,000 characters. The setup for the state side is covered in this guide to building an MCP server.

A failure rule. Each agent CLI runs as a real PTY child process, so AuricIDE reads a real exit code. One failed step stops the chain, and later steps never receive that failure as though it were a valid handoff.

The cleaned tail is what makes different CLIs interchangeable: every harness already produces terminal output, so chains need no vendor-specific result format. It is also the weakest link. Something important can sit outside the last 2,000 characters. What survives is prose the next agent still has to interpret.

How do you add a CLI without rebuilding the app?

You describe it in a file. No adapter needed.

Adding a CLI through app code ties support to a release. A changed flag means editing an adapter, rebuilding, and shipping that build to everyone. AuricIDE puts the harness details in a dynamic provider instead: one JSON config per CLI, imported under Settings → Agent, describing how to start the command and handle its input. A skill then uses that provider.

Validation happens at import. One missing or wrong field rejects the whole provider file, and AuricIDE writes the reason to stderr while other valid providers keep loading. The timing is the point. A bad config announces itself while you are looking at it, instead of surfacing later as a murky process error inside a chain.

The dynamic provider removes the rebuild, not the constraint. Each CLI still has to fit the schema, so its prompts, flags, models and permission behaviour must map onto supported fields. A CLI with a genuinely new convention needs a schema change or custom wiring. No amount of config gets you around that.

AuricIDE starts the command in a pseudo-terminal, which is why prompts and the real exit status stay part of the run at all. Python's pty docs describe the same idea in plain terms: a child process attached to a terminal rather than to a bare pipe. Different language, same model.

What does the framework cost you?

Local glue, traded for shared rules. That is a good trade at some sizes and a bad one at others.

Two rows deserve more than a table cell. A fixed chain is the wrong shape when incoming tickets need routing and retries instead of a fixed sequence; the guide to AI agent workflows covers that case. Running locally cuts both ways too. AuricIDE is a desktop application, so your code and your project record stay on your machine. Nothing runs off it. Nothing is watched for you. Work does not spread across machines. The licence is a separate matter. AuricIDE is open source under AGPL v3, which lets you read and change the source. Pass that changed version on, and the same terms travel with it.

MCP changes who can reach project data, too. Someone reading tickets needs less access than someone editing them, so a review skill can live on read-only while a skill that writes code cannot. The framework hands you reusable permission modes. The policy stays yours.

For a single project with one stable script, a shell script is clearer and cheaper. You control every argument and shape each handoff for that one CLI. The bill arrives later, once those choices are spread across scripts, terminals and people. A framework earns its place at the point where shared rules cost less than the wiring you keep redoing.

What carries across to any other tool?

The five rules underneath, none of which name a product.

Start with one workflow that has clear handoffs. Write down each step's owner, required context, expected result, permission level and failure condition. Note what the next agent needs from terminal output a person copies by hand today. That list is the specification.

Then describe the harness without framework vocabulary: the command, the input method, the valid exit behaviour, the output worth keeping. Such a record makes CLI changes easy to trace. It also keeps the integration legible to whoever arrives later.

Test failure before success. Make one step return a nonzero exit code. Check that later work stops, that an operator can find where it stopped, and that shared state does not claim the step finished. Then test a long, noisy terminal result. Check that truncation still leaves enough context for the next task. Both are cheaper to learn now than during a real run.

Compare against the manual version while you still remember it. Elapsed time, human actions, failed handoffs and reruns are the numbers that matter. With paid models, the cost of a run belongs beside them. A cheap run that somebody has to repair is not a cheap run.

Keep the durable rules small. Define each harness. Store shared state. Pass context on purpose. Stop a chain that is not safe. Show the operator where attention is needed. AuricIDE implements all five with dynamic providers, skills, chains, MCP project state and the Fleet view. Permissions, review and release stay your call whichever tool you pick.