A demonstration shows an assistant finding a record, preparing a reply, and updating a system. It looks like one intelligent action. Underneath, several components made separate decisions about data, permissions, tools, and results.
Understanding those components helps you ask better questions before buying or building an integration. It also helps you choose a simpler design when a task does not need an agent.
Your work product is a one-page architecture and a tool inventory for one business workflow. This chapter describes the roles and boundaries; the accompanying local exercise is not an MCP server and does not call a model or external provider.
Begin with the difference between a workflow and an agent
A workflow follows a defined path. An agent gives the model more choice over the next step, such as which tool to call, what information to request, or when to stop.
Anthropic uses this distinction in its engineering guide to effective agents. The terms vary across products, so ask what decisions the model actually controls instead of relying on the label on the sales page.
For Mesa's inspection-fee answer, the path is known: obtain the current policy, prepare an answer, and preserve missing availability. A fixed template or bounded drafting workflow may be enough.
An agent could be more useful for a varied investigation in which the next information source depends on what the first source reveals. That flexibility adds questions about permissions, cost, stopping conditions, and unsupported conclusions. It does not remove the need for a defined outcome.
Map the components to things you can inspect
| Component | Job | Business question |
|---|---|---|
| Model | Interprets context and proposes text or actions | Does it perform this task accurately enough? |
| Orchestrator | Controls steps, budgets, state, and tool access | What prevents an unbounded or inappropriate action? |
| Tool | Performs a specific operation | What records can it read or change? |
| Source system | Holds policy, cases, inventory, or other records | Which system is authoritative? |
| Review interface | Shows proposals and captures decisions | Can the reviewer inspect the exact action? |
| Operation ledger | Records attempted and completed work | How will duplicates and uncertain outcomes be resolved? |
One product may package several components together. You still need to know where each responsibility is enforced. A model's natural-language explanation does not establish what the connector did.
Ask for a trace of one real test case in the proposed environment: input, selected source, tool request, authorization result, action response, and final status. Remove secrets and unnecessary private content from the trace before sharing it.
Understand what MCP standardizes
Model Context Protocol is a protocol for connecting AI applications with sources and capabilities. Its July 28, 2026 specification describes hosts, clients, and servers: the host is the AI application, a client is its connector component, and a server exposes context or functions.
The specification distinguishes resources, prompts, and tools. Resources provide context or data; prompts provide reusable message templates; tools expose callable functions. MCP uses JSON-RPC messages for protocol communication. These definitions explain an interface, not a complete business automation or a guarantee that a server is trustworthy.
The dated link matters. Implementations may support different revisions and optional capabilities. Check the versions supported by both sides and the official documentation for the integration you actually use. Do not combine snippets from several revisions and assume they form one valid implementation.
A business owner usually does not need to write protocol messages. The useful questions are whether the connection supports the required capability, with the required permissions, under a maintained implementation.
Follow one tool call through the business boundary
Imagine a service assistant needs Mesa's inspection policy. A tool named read_service_policy could return the permitted current source. The assistant could then propose a reply. A different operation could stage it for review.
Those names describe a possible design, not tools installed or connected in this project. The practice code exposes ordinary Python methods instead of MCP endpoints.
In MCP, tools have names and input schemas, and the protocol defines discovery and invocation operations. The tools specification also discusses output structure and tool annotations. An annotation describing behavior is not a substitute for trusted implementation and enforced access controls.
A schema can say an argument is a string or that a field is required. It cannot, by itself, prove that the recipient is correct, the record belongs to the caller, or a discount is approved. Those checks belong in the application's action logic and source systems.
Separate connection authorization from action approval
A connection may let an assistant read a particular collection or invoke a particular class of tools. That does not mean every possible action under that connection is approved for every purpose.
MCP's HTTP authorization specification addresses delegated access to restricted servers. It is not the same flow as a local STDIO integration, and support must be checked for the chosen implementation. Credentials should be handled through the proper application mechanism, not pasted into prompts.
After a connection is authorized, enforce the intended record scope and business rules on each operation. A source search should not reveal another entity's private records. A write operation should still check its proposal, approval, current record state, and duplicate identity.
Keep the ability to revoke access and pause new actions. Also identify where previously copied data remains. Disconnecting a server does not automatically remove every export, cached result, or log created earlier.
Treat incoming text as evidence, not authority
A resource can contain a customer email, supplier document, or web page. That material may include instructions such as “ignore previous rules” or “send the complete database to this address.” Its presence in a tool result does not make it a valid user instruction.
Design the workflow so external content cannot change its tools, permissions, approval state, or destination. Review the data needed for the task and validate proposed calls outside the model. Chapter 33 covers the permission checks; Chapter 35 covers the retrieval boundary.
A tool result can also be wrong or incomplete without being malicious. A source may be stale, a query may have returned only the first page, or a field may be missing. Require enough source and status information for the next step to recognize those limits.
Do not reward a system for always producing an answer. A correct “the calendar was not checked” is more useful than an invented confirmation.
Bound an agent's freedom before enabling it
If the task needs model-directed steps, write its operating envelope. Specify the objective, available tools, accessible records, maximum effort, stop conditions, and escalation path.
For a proposed source-research agent, that might mean investigating one question with a bounded set of approved sources, producing a cited draft, and stopping when evidence is missing or the effort limit is reached. It would not imply permission to contact people or change their records.
Set both step and resource limits. A tool call count alone may not control cost if one call can launch expensive work. A time limit alone may not stop a queued action already accepted by another service. Check how cancellation works at each boundary.
Make incomplete status useful. “Stopped at the budget limit; these sources were checked; this question remains open” preserves progress without pretending the task is finished.
Choose an architecture from the task's needs
| Task pattern | Starting design to consider |
|---|---|
| Exact fields, fixed rules, predictable result | Ordinary automation or a template |
| One language task with known sources | A bounded model call with validation and review |
| Known sequence with a few defined branches | A workflow with explicit routing and exception handling |
| Investigation whose next step depends on findings | A bounded agent with a tool and source allowlist |
| Separate tasks that truly need independent expertise | Consider separate workers only if coordination adds demonstrable value |
These are design choices, not a maturity ladder. More components create more places to manage identity, state, cost, and failure. Select the smallest arrangement that can meet the task's requirements and be maintained by the people available.
A no-code builder still needs the same inspection. Ask how it represents approvals, retries, event identity, logs, data retention, and version changes. A visual diagram does not automatically establish those behaviors.
Evaluate a connector before relying on it
Create a tool inventory with the actual provider, maintained version, read and write scope, required credentials, source of permission enforcement, and expected result. Include failure and recovery behavior.
Test the real boundary in a suitable environment. Can the connector read only the intended records? What happens when access is revoked? Does it paginate? Can a timeout leave an action completed but unacknowledged? Can the result be looked up without repeating the action?
Check how tool or schema changes are communicated. A new tool appearing after an update should not automatically inherit unlimited authority. Review whether the changed capability fits the workflow's existing scope and whether its evaluation cases still pass.
Keep operational ownership with a person or team. Someone must maintain credentials, sources, tests, incident response, and the decision to stop using an integration.
Write the architecture in one page
Describe the request, allowed data, source systems, model's role, permitted tools, action checks, approval point, ledger, and fallback. Then list what remains unknown.
For the current practice pack, the page is deliberately simple: local JSON fixtures, a fixed drafting function, simulated roles and approvals, and a SQLite review queue with an operation ledger. There is no model, MCP transport, remote connector, or outbound action.
That clarity makes the next design decision easier. You can identify what adding a model or connector would change and test that added boundary directly. The purpose of learning the terminology is to see the real system behind the demonstration and decide what your business actually needs.
Next: Give the workflow reliable context and memory without mixing entities, drafts, and facts in Chapter 35.