What an agent needs to work

IT gets the brief on a Monday: “we want an agent to handle collections”. On Tuesday they discover the ERP has no documented API for querying overdue invoices. On Wednesday, that bank payments arrive as files someone downloads by hand. On Thursday, that the rule for whom to call first isn't written anywhere. By Friday, the agent project has become a six-month integration project.

Another composite, and it sums up why so many agents stay stuck in the demo. The model was capable from day one. What was missing was everything around it. This episode goes through those pieces, one by one.

Operational APIs: the agent's hands

To act reliably on systems, an agent needs controlled interfaces: draft an invoice, record a payment, update a CRM stage or open a ticket. It can produce useful work without writing to those systems, but making changes requires an authorized, verifiable mechanism. Every exposed action is also a risk surface: narrow what can be done, with which parameters and validations.

Analytical APIs: the agent's eyes

Querying data is different from acting on it. An analytical API can answer questions such as balances by customer, sales by period or overdue invoices by age. Separating it from operational interfaces lets teams apply different controls. Reading still needs permissions, role filters and records, especially for sensitive data; actions add validations and, according to impact, approvals.

The semantic layer: the dictionary

As we saw in the previous episode, querying governed metrics reduces the need to improvise formulas. When a process depends on business indicators, a semantic layer can give the analytical API versioned definitions. It does not replace source quality, permissions or validation of each answer.

Tools: the contract

A capability can be presented to the model as a tool: a name, a description and a parameter schema. That looks like an implementation detail, but it affects what the agent selects and how it uses it. Narrow tools with validation and clear errors make testing easier; teams must still measure whether the model selects the right one on real and adversarial cases.

The model decides which tool to use. The quality of that decision depends on how well the tool is designed.

Skills: the procedure

Tools say what an agent can do. Skills are one way to document how a task is done in this company: instructions, examples and resources for reconciliation steps, collections order or checks before proposing a discount. Some platforms load these packages when needed; others organize procedures differently. Either way, they need versioning, tests and an owner.

MCP: the common plug

For years, connecting a model to each system required a custom integration. The Model Context Protocol, an open standard Anthropic introduced in late 2024 and other major providers later adopted, defines a common way to expose tools, resources and prompt templates to compatible clients. Those templates are not executable procedures or a replacement for a team's skills. We devote the next episode entirely to it, because it changes what an organization can do from the AI tools its team already uses.

The order of construction

This infrastructure isn't built all at once for the whole company. It's built for the first process, designed so the second can reuse connectors, permissions, evaluations and records. Semantic definitions belong in processes that query business metrics. A second agent may cost less when those pieces are genuinely reusable. Before production, every action needs limits, tests and traceability proportionate to its risk.

The scenes in these episodes are composites of common situations, not customer cases. Any figures in them are illustrative.