LLM Agent Architectures: Three Shapes That Matter

One Agent Is No Longer Enough

Tuesday evening. A coding agent has spent forty minutes editing two services when a change request lands. Its prompt history is full of diffs, test output, and dropped plans. Earlier decisions blur. One terminal response ends mid-line. Then a second agent opens the same repository to check the change. The two histories now disagree. Both processes can still edit the same files, and neither knows whose decision wins.

The model isn't the problem here. The real problem is picking a shape that shows a failure before another agent builds on top of it. That difference matters once one coding loop turns into several: see the earlier guide to AI agents versus LLMs for the line between a single model call and a system that acts.

One agent keeps ownership simple. One conversation records the request, tools, corrections, and patch. A bad edit has a visible source. Context is the constraint. As the log grows, older output competes with the next decision. Unrelated work waits.

Opening another terminal removes that wait. It also creates a new line to draw. Somebody must decide what each process owns, what the next process gets to see, and what happens if either one fails. Adding more agents doesn't answer any of that on its own.

Three shapes cover that decision. A single loop keeps work inside one history. A chain gives each step a bounded result from the previous step. A fleet runs independent processes against shared project records. Choose among them by asking which failure must stay contained.

What Does AuricIDE Do With Several Running Agents?

AuricIDE gives each agent a local terminal process, then sorts the fleet by which process needs attention.

A new session gets a project, task, provider, model, and permission mode. It opens as its own PTY child process. Its terminal remains available beside other sessions. If one process crashes, its failure does not terminate the others. Unrelated work can continue while the failed slice waits for a decision.

Process completion becomes a small status code. AuricIDE records 0 for an idle result, 1 for a failed process, and -1 when waiting on the child fails. Those three values map success or failure. They do not show the child process's own exit code.

The fleet view does not give every card equal weight. Its attention list puts errors first, prompts needing input second, and stalled agents third. Reviewed failures leave that list. Running work without a prompt or stall stays out. This turns monitoring into triage instead of a repeated scan across terminals.

For monitoring, the useful signals are concrete: process exit status, terminal output, and whether the agent needs input. A practical AI agent monitoring reference should therefore focus on those events rather than a vague activity indicator.

Coordination needs a record outside the terminals. AuricIDE stores goals, tickets, requirements, test cases, dependencies, and status history in .auric/project.db inside the project folder. A .auric/.gitignore containing * keeps that record on the current machine. A fresh clone has no work record.

Agents use auric-pm to read and update that record. The MCP server starts for the project and communicates over stdio. There is no listening socket. There is no port or background daemon for clients to discover. MCP can expose tools and workflows through a standard interface that clients and custom agents call, as described in the MCP agent integration reference.

When Should Work Become a Chain?

A chain fits when each stage needs the previous stage to finish before it can begin.

Consider an ordered combo with three skills: inspect requirements, implement the change, then run a focused review. AuricIDE starts one step. That step owns one agent. When it finishes successfully, the next step starts in the same project. There is one current step index and one current agent, so the combo cannot fan out or merge parallel branches.

The handoff is deliberately narrow. AuricIDE takes the tail of the previous terminal, strips ANSI codes, removes interface chrome, and deduplicates redraw lines. The newest useful lines win. The result stops at 2,000 characters. It is a cleaned terminal tail, not raw stdout and not a complete summary.

That boundary can discard an early decision. Important requirements therefore belong in the project record or the next step's explicit instruction. The tail offers a lead, not evidence.

Failure stops the combo. No downstream reviewer starts against work that the failed implementation step was expected to produce. The interruption costs time, but continuing would hide the broken premise.

The chain trades concurrency for order. It suits work with a real dependency between stages, and it delays everything behind a slow step: a chain is only as fast as its slowest link, by design. A framework can organize that work, but it can't remove the decision, as the agent orchestration framework discussion also leaves clear.

What Does a Fleet Cost?

A fleet costs explicit ownership, database contention, and human decisions about overlapping edits.

Parallel terminals do not prove that tasks are independent. Two agents can change the same migration, rename the same symbol, or satisfy one test in incompatible ways. AuricIDE keeps both processes visible, but it cannot decide which edit should win. File ownership still needs a person or a written task boundary.

Shared state has a smaller bottleneck. The project database runs in WAL mode, while auric-pm accesses it through synchronous better-sqlite3. One writer operates at a time. Another write waits. That is acceptable for short project-record updates, but it rules out treating the database as a high-volume event bus.

Local storage also has a sharp edge. The database stays beside the project but is ignored by Git, so cloning the repository does not copy tickets or history. Moving the folder on the same machine keeps the file. Sharing the work record requires a separate export or transfer.

A fleet is also where teams tend to mix CLIs: one provider for review, another for the actual edit. Each one is a separate config to get right. Settings > Agent can import a JSON config for an external CLI without a rebuild, and a bad import is rejected on the spot. A file dropped straight into the provider folder is different. At startup, a broken one is just skipped and logged to stderr while the rest keep loading, and that error never shows up on screen. Mix more CLIs into a fleet, and more of these silent skips become possible.

The fleet earns these costs only when independent work can continue. Market adoption does not answer that design question. Recent market data describes multi-agent systems as 53.30% of the agentic AI market in 2025, with a projected 43.50% CAGR through 2031, according to Mordor Intelligence's agentic AI market report. Those figures describe market structure, not a guarantee that a fleet fits a particular repository. A concrete failure boundary matters more than category growth.

What Should Survive a Tool Change?

The durable lesson is to pick a failure boundary before picking an agent count. No single shape wins by default. A separate enterprise benchmark tested 18 configurations across orchestration, prompting style, memory, and tool use, and found that different models did better with different setups, not one setup for all (enterprise LLM agent architecture benchmark).

Start with the workload that can go wrong. If the task has one owner and one branch, a single loop keeps ownership and correction together. If stage B would be invalid before stage A completes, a strict chain can define the handoff. If one blocked task should not stop another, separate processes need a shared ownership record.

Then price the boundary. Every tool call adds more output. Each agent that receives it gets less history, or has to reread old output. Every extra writer creates more work to stay in sync. A recent clinical benchmark found that adding web browsing, code execution, and text editing to a single agent produced only modest accuracy gains while driving more than 10× token usage and more than 2× latency, as reported in the clinical LLM agent benchmark. Even one added capability can cost more than it returns; a whole extra agent, with its own history and its own database writes, is a bigger bet still. Make it when the task needs the extra control, not by default.

The interface will change. The questions will not. Who owns the next action? Which information does the receiver get? Which failure stops later work? Which failure can wait while other work continues?

AuricIDE offers a local desktop workspace for running CLI coding agents as single loops, ordered combos, or repository-based fleets, with dynamic providers and MCP-backed project state. Engineers exploring these LLM agent architectures can examine the workflow and its trade-offs at AuricIDE.

Pick the smallest shape that contains the failure.