How to Create an AI Agent That Actually Ships

How to Create an AI Agent That Actually Ships

What breaks when a second agent starts?

The second agent breaks the first agent’s unwritten assumptions. Picture Tuesday afternoon. Agent A renames a configuration file. Agent B edits the old path. Both terminals stay busy. A third agent reviews a repository state that neither writer meant to create. Nothing in those prompts says who owns the file.

The conflict starts before the diff: both agents accepted tasks built on different versions of the same repository.

The tempting fix is a sharper model. That misses the failure. Once several processes can write to one repository, every change needs an owner, a visible status, and an agreed handoff point. Prompt quality still matters. Coordination now matters too.

Practical rule: Give every write one owner, then make completion and failure visible before another agent depends on it.

The agent orchestration framework guide matters here because orchestration isn't a decorative layer around prompts. It decides which process starts, what task it receives, and whether later work may begin. AuricIDE acts as a meta-harness above coding CLIs. The app does not make each agent cleverer. It gives separate runs a shared control surface.

What does AuricIDE put in front of the user?

AuricIDE puts provider registration, agent terminals, fleet status, and reusable launches in one desktop workspace. Start under Settings → Agent. Select a provider JSON file. AuricIDE reads it, checks its id, saves it to the app's data folder, and registers the provider right away. No restart is needed.

Open a project next. The launch dialog shows the registered provider, its models, and its permission modes. Enter a bounded task, choose the access level, and start the run. AuricIDE adds the session to the fleet view. Opening it reveals the terminal. Text can be sent back when the CLI requests input. Output from another agent remains separate.

The imported record describes the executable, arguments, models, permission modes, and version check for that CLI. A broken import produces a visible error. The provider list remains usable. This route matters because dropping JSON straight into a provider directory behaves differently. The registry scans those directories during application setup. A file added there appears after the next start. If that file is malformed, AuricIDE skips it, writes the error to stderr, and still loads every valid provider file.

The agent integration guide is the useful companion when the concern is registration rather than coordination. Once registered, a provider becomes a launch choice. Each agent then runs as its own local PTY child process, with a separate terminal and lifecycle. One crash does not stop the other processes.

AuricIDE reduces each stopped process to success or failure. Exit status zero becomes idle. A nonzero status becomes error. A failure while waiting on the process also becomes error. The fleet view does not show the child's numeric exit code, so you still have to read the terminal to know exactly what happened.

The attention list answers a narrower question: which run needs a person now? Errors come first. Input prompts follow. Stalled runs come last. Within those groups, earlier waits rise first where AuricIDE has an honest timestamp. Clean finishes ask for no attention.

Two reusable objects sit nearby. Their names can mislead. A launch preset stores a prompt plus provider, model, and permission choices in application preferences. A discovered skill comes from paths scanned in the repository or user skill directories. Its record contains an invocation, name, description, source, scope, and file path. It carries no provider, model, or permission mode. Its launch settings come from a separate choice or the provider defaults.

For example, a review-only preset can keep one prompt tied to a read-only mode. A repository skill named diff-reviewer supplies an invocation and location. It does not inherit the preset.

How does work pass from one agent to the next?

AuricIDE passes work through a combo, a strictly sequential chain of launch presets inside one project. One step runs at a time. There is one current index. There is one current agent. No step fans out, and no later steps join parallel results.

A three-step feature run could start with an implementer, continue with a read-only reviewer, then finish with a test runner. Each step may pin its own provider, model, and permission mode. If a step fails, the combo stops. Later prompts assume that earlier work exists, so continuing would spend tokens on a false premise.

A successful step starts its successor with two inputs: the next prompt and a cleaned tail from the previous terminal. AuricIDE strips ANSI escapes, filters interface chrome, and removes repeated redraw lines. It then fills a 2000-character budget from the newest line backward. This is not raw stdout. Long sessions are cut off, sometimes before the useful explanation.

That handoff supplies immediate context. Project records define the work contract. AuricIDE records goals, tickets, requirements, test cases, dependencies, and history in <project>/.auric/project.db. AuricIDE places the SQLite file on the project’s git ignore list, so another clone receives no project record. The database uses WAL mode and a single synchronous writer through better-sqlite3.

The auric-pm MCP server exposes that state over stdio. Separate agent processes can inspect or update the same records through that connection. There is no listening socket.

The guide to building an MCP server covers the connective layer in more depth. For a fleet, the useful distinction is simple. A terminal tail contains output from the last process. The project database contains work items and their relations.

What does this design cost?

The design costs parallel speed, portable project history, and some simplicity. Combos cannot branch. A long terminal explanation may fall outside the handoff limit. Different CLIs may interpret shell quoting or commands differently, even after the text is cleaned. The next agent must inspect the working tree before trusting the tail.

Local storage has another sharp edge. Keeping .auric/project.db out of git avoids database diffs and keeps the record on one machine. It also blocks collaboration through a clone. An agent with write permission can alter the same goals and tickets used to judge its work. Permissions still need care.

Being able to add any CLI has a cost too. Importing through Settings gives an immediate check. Dropping a file in by hand only gets picked up at the next start, and its errors go to a log nobody reads by default. Neither path proves the external program will behave well once it's running.

Running more agents can also spend money badly. One in five organizations couldn't stop runaway AI-agent spending in real time, and 85% used two or more orchestration tools, 64% used three, according to reported enterprise orchestration findings. A fleet needs stop controls, bounded retries, visible failures, and explicit permissions before extra concurrency pays off.

What survives a change of tools?

The coordination rules survive: assign ownership, bound each task, preserve a visible handoff, and stop when the recorded state contradicts the run. Those rules work with another IDE, a shell script, or several terminal windows.

Start with ownership. Name the files or responsibility each agent controls. Record dependencies outside chat. Treat terminal output as evidence, not memory. Give write access only where the task needs it. Make failure louder than motion. A busy terminal proves little.

The second agent creates a fleet only when its work becomes answerable to shared rules. Provider names will change. Models will change. Prompt formats will change. The need for an owner and a checked handoff will remain.

AuricIDE provides a desktop workspace for registering CLI providers, saving launch presets, composing ordered chains, and exposing project state over MCP. Visit AuricIDE to examine the open-source meta-harness and decide whether its fleet model fits the way your agents already run.