The agent is the new integration layer

Here's how answering one routine question looks in most businesses I've seen: CRM for the record, calendar for the slot, inbox for the thread, accounting app for the invoice. Four windows. For decades the official answer to "these systems need to talk" was an API bridge, a sync job, a Zapier flow. The unofficial answer was you, copying values between windows. The user has always been the real integration layer.

That's the job conversational agents are actually taking. Not writing poems. Integration.

One interface, every application behind it

An agent with tool access inverts the integration problem. Instead of wiring N systems to each other (N×N bridges, each one maintained forever), you expose each system as a handful of small typed functions facing one agent. The conversation becomes the front-end of everything at once.

The agent I built for Cassie, our clinical case-management platform, sits in a drawer next to the main UI. While writing this post I actually counted the tools registered behind it: 46. I would have guessed thirty. They span what would normally be five separate applications:

• Case data — find a claimant, summarise a case, list overdue items, pull a full timeline
• Calendar — search events, list proposed slots, find free slots for the next session
• Email — search correspondence, list a claimant's emails, send a templated message
• Documents & questionnaires — read a document, pull PHQ-9 progression
• Analytics — outcome stats by insurer, cohort averages, similar historical cases
• Accounting — create an invoice, check its status, list overdue ones — wired straight into FreeAgent, the real bookkeeping system
• Memory — rememberFact, recallFact, forgetFact — operator-approved notes that survive across sessions
• Drafting — session prep, progress reports, clinical summaries generated from case context

The operator types: "prep me for tomorrow's session with M., and check if her last invoice was paid." Find claimant → read timeline → pull questionnaire progression → draft the prep → query FreeAgent → one answer. Four applications and fifteen minutes of swivel-chair work, collapsed into a sentence.

The part people get wrong: an agent is not an LLM

Because you talk to it, you assume the language model does the work. In any agent worth using, the model is a thin decision layer — by volume of work done, a few percent. Strip a production agent to its skeleton and you find:

1. A tool manifest — typed functions with names, descriptions and parameter schemas (findFreeSlots(range), getInvoiceStatus(ref)). This is the real capability surface: no tool, no power.
2. The loop — your message goes to the model with the manifest; the model picks a tool, the runtime executes it against the live system, the result comes back, the model decides again. One question can mean five hops.
3. A system prompt — role, rules, refusals.
4. Memory — explicitly stored facts, recallable next week.
5. Guardrails — rate limits, budgets, draft-only writes.

The lookups, computations and side effects are ordinary deterministic code. Testable. Boring, in the best way. What the LLM contributes is the choices and the final sentence — the dispatcher, not the workforce. Once you see it that way, it stops being a chatbot feature and starts being an integration technology.

Why the integration framing pays

Trust. When the agent says an invoice is unpaid, that's not a model's recollection — it's the accounting API's response from two seconds ago, surfaced conversationally. Agents earn trust precisely where they stop relying on the model and start calling systems.

Engineering economics. N small tools instead of N×N bridges. Each tool is testable in isolation; adding an application to the agent's reach is an afternoon, not an integration project. When something breaks, you debug a function, not a prompt.

One more thing, and it took me embarrassingly long to internalize it: the only hard requirement is API access. The rest is simple. If a system exposes a programmatic surface, turning it into an agent tool is a function signature and an honest description — that's how FreeAgent joined Cassie's conversation, in an afternoon. The real moat between you and a fully conversational stack isn't AI engineering. It's whether your vendors let you reach the data you already own.

Safety. Capability lives in the manifest, so restraint does too. In Cassie's case: reads are plentiful, writes are few and drafted — generated summaries land as labelled proposals, emails go from templates the operator reviews. The agent prepares; the human pulls the trigger.

Where this goes

Every application you use is one tool manifest away from joining the conversation, and manifests are becoming portable — MCP-style protocols are precisely "integration descriptors for agents". The endgame: you stop asking "which app do I open?" and start asking your agent, the only party that needs to know where everything lives.

The glue layer finally has a user interface, and it's a sentence. Just don't mistake the sentence for the system underneath it.