Stop Calling Everything an Agent: Ship an Architecture Contract Instead

The word “agent” has become too convenient. A product team can use it for a chat assistant, a retrieval app, a workflow with a model step, a copilot that waits for approval, a coding tool that edits a repository, or a system that plans and executes multi-step work while the user only sees the result. Those systems do not carry the same risk. They do not need the same telemetry. They should not pass the same review.

That is the useful signal in Irene Weber’s new arXiv survey, Forms of LLM-Integrated Applications from LLM-Chats to Autonomous AI Agent System. The paper does not treat labels like chatbot, RAG, workflow, copilot, coding agent, and AI agent as interchangeable marketing words. It asks whether those labels point to real architectural forms. Its abstract argues that, at least in vendor usage, they often do: a copilot tends to operate a host application through a router-worker pattern with step-by-step user confirmation, while the “agent” label increasingly describes AI-planned multi-step execution where the user sees the outcome rather than every internal move.

That distinction matters because most enterprise AI failures are not caused by the noun on the roadmap. They come from mismatched authority. A team says “assistant,” but the system can write to production data. A vendor says “workflow,” but the model can choose tools dynamically. A demo says “copilot,” but the human only approves the final answer after side effects have already happened. By the time security, compliance, or operations sees the gap, the implementation is already politically expensive to change.

The fix is simple: stop approving the label by itself. Every LLM-integrated system should ship with an architecture contract.

An architecture contract is not a 40-page governance document. It is a short, explicit statement of how the system works. It names the form being deployed, where control changes hands, which tools the model can touch, how many loops it can run, where humans intervene, and what evidence the system will preserve. It turns “we are launching an agent” into a reviewable claim.

Start with the form. Is this a chat interface that only generates text? A RAG assistant that retrieves documents and answers questions? A predefined workflow with model calls at fixed steps? A copilot operating inside a host application with user confirmation? A coding agent with file-system and shell access? A longer-running autonomous executor? The form is not decorative. It tells reviewers where to look for failure.

A RAG assistant can fail by retrieving stale or irrelevant evidence, over-summarizing policy, or presenting a confident answer without source boundaries. A copilot can fail when the approval screen hides the real action. A coding agent can fail by editing the wrong file, running an unsafe command, or carrying stale assumptions across a repository. A back-office execution agent can fail by retrying a side effect, skipping an exception, or completing the wrong customer record. Calling all of them “agents” erases the specific control needed for each one.

The second field is the control point. Anthropic’s guidance on effective agents draws a practical line between workflows, where code defines a path, and agents, where the model dynamically directs its own process and tool use. That difference should be visible in the contract. If code owns the sequence, the review should focus on branch logic, data validation, and the quality of each model step. If the model owns the sequence, the review must also cover planning limits, tool selection, retries, stop conditions, and escalation.

The third field is the intervention point. “Human in the loop” is too vague to be useful. Does the person approve every proposed step? Only high-risk actions? Only the final result? Only exceptions? Can the person inspect the evidence behind a recommendation before approving it? Can they cancel the run after a tool call but before a write? A copilot that asks before every action has a different safety profile than an agent that asks for approval after composing a batch of side effects.

The fourth field is the tool surface. OpenAI’s Agents SDK documentation exposes the practical vocabulary here: agents, tools, handoffs, guardrails, and tracing. Those are not just framework features. They are deployment boundaries. A system with read-only search tools belongs in a different class from one with write APIs, shell access, browser control, payments, credentialed customer systems, or PHI-adjacent data. If the tool surface changes, the architecture contract changes.

The fifth field is the loop budget. How many model/tool turns can the system take before it must stop, ask, or escalate? How many retries are allowed? Are retries idempotent? Can the model call the same write tool twice? Can it continue after partial failure? Long-running agents need this because persistence changes the incident shape. A one-turn assistant usually fails in front of the user. A multi-step executor can fail quietly across time, tools, and records.

The sixth field is evidence. The contract should say which traces, approvals, tool inputs, outputs, handoffs, receipts, and final artifacts are retained. This is not just for audit. Evidence is how operators debug the gap between “the model said it succeeded” and what actually happened. For coding agents, Anthropic’s Claude Code documentation makes the high-agency surface obvious: the agent can work in a terminal-like development environment, inspect files, edit code, run commands, and iterate. That is powerful, but it also demands a record that distinguishes reasoning, file changes, shell output, test results, and human approval.

A useful architecture contract can fit on one page:

• Form: RAG assistant, workflow, copilot, coding agent, autonomous executor, or other declared class.
• Control point: predefined code path, model-planned path, or hybrid.
• Intervention point: every step, before side effects, before high-risk actions, after completion, or exception only.
• Tool surface: read, write, shell, browser, API, financial, clinical, identity, or other sensitive tools.
• Loop budget: maximum turns, retries, timeout, cancellation, and escalation behavior.
• Evidence: traces, approvals, source documents, tool payloads, outputs, receipts, and replay material.

This does not slow teams down. It prevents false alignment. Product can still say “agent” in the launch deck, but engineering, security, and operations get the artifact they need to evaluate the real system. Procurement can compare vendors on control surfaces instead of adjectives. Compliance can ask whether the declared intervention point matches the actual workflow. Incident responders can know where authority moved before something went wrong.

The bigger lesson is that agent adoption is moving from demos to deployment classes. The next mature organizations will not be the ones with the most agent labels. They will be the ones that can say, precisely, what each system is, what it can do, when it must stop, and what evidence proves it behaved inside its boundary.

If the label is “agent,” the next question should be: which architecture, under what contract?