Why We Build Agent-First, Not Agent-Bolted-On

01 — the bolt-on trap

A chat box in the corner inherits every old assumption

An LLM wired into a corner of the UI inherits every assumption the app already made. The data model wasn't built for it, the permissions weren't built for it, and the failure modes weren't built for it. You end up defending the seams instead of shipping capability.

02 — what the field learned the hard way

Most of these projects never reach production

This isn't a hunch. MIT's 2025 State of AI in Business study found that the vast majority of enterprise generative-AI pilots produced no measurable P&L impact — and named the cause a "learning gap": the tools don't retain feedback, adapt to context, or integrate into real workflows. A chatbot with a system prompt does none of those things.

Read those numbers carefully — they're about pilots and projections, not the ceiling of the technology. But the pattern behind the successful minority is consistent: agents wired into real systems and real data, with a job to finish, beat assistants that only talk.

03 — agents in command, humans in control

Design the agent as the operating core

We start from a different question: what does the system do on its own, and where does a human step in? A supervisor orchestrates declarative agents that each own a narrow job. Every state change is proposed, not applied — a person approves it. The human UX sits alongside the agent layer, not on top of a chatbot.

04 — name your architecture

These are recognised patterns, not improvisation

The vocabulary has standardised. Anthropic's Building Effective Agents draws the line between workflows — LLMs on predefined code paths — and agents that direct their own steps, and advises starting simple, adding autonomy only where it demonstrably helps. LangGraph names the topologies — supervisor, network, hierarchical — and makes the handoff (passing both control and state) the core primitive. OpenAI's Agents SDK reduces the whole thing to three first-class objects: agents, handoffs, guardrails.

We reach for the supervisor topology by default — narrow, declarative workers under a router, because the traces stay legible and a new capability is a new worker, not a rewrite. We add handoffs only where a specialist genuinely owns the next move.

05 — propose, don't apply

The approval gate is a first-class mechanism now

"A human approves it" isn't a promise stapled on at the end — the frameworks make it structural. LangGraph's interrupt() pauses a run at a node, persists the entire graph state through a checkpointer, and resumes from that exact point once a human responds — minutes or days later. OpenAI wraps each agent in input/output guardrails; Azure formalises the same idea as maker-checker review loops.

The canonical trigger is precisely the one that matters in production: an agent decides to do something real — send the email, run the query, place the order — and a person approves, edits, or rejects it first. Designing for that from the outset is what makes audit and rollback cheap instead of impossible.

06 — the honest caveat

More agents is not automatically better

Agent-first doesn't mean "spawn a swarm." Anthropic's own research system beat a single agent by a wide margin on breadth-first research — while burning roughly fifteen times the tokens. Cognition, building a coding agent, argued the opposite case in Don't Build Multi-Agents: parallel agents with split context play telephone and ship conflicting decisions. Both are right about their workload. The reconciling lesson everyone converges on is context engineering and bounded autonomy, not agent count.

07 — what it buys you

New capability becomes a new agent, not a new screen

Agent-first is more work up front. It's also the only version we've seen survive contact with real users.