Agent Economy: Connecting AI to Business Management

Conversations about AI agents often begin with what they could do. For a business, a more useful question is: what contract, credential, and review does each action require? Without those three elements, an impressive demonstration does not become a dependable process.

An assistant can explain how to prepare an invoice. An agent connected to tools can query a client, propose operation fields, or send a request to an API. That difference increases usefulness, but it also increases the impact of an ambiguous instruction. Reading, proposing, and executing should therefore remain distinct stages.

From a conversation to a concrete tool

An AI system should not “enter the ERP” in a generic way. It should select a tool with a defined name, description, and argument schema. The business system then validates authentication, processes the request, and returns a structured result.

This contract makes important questions answerable:

• does the operation only read, or can it change data?;
• which account and resource does it target?;
• which fields are required?;
• what errors can it return?;
• who reviews the result before the next step?

The more sensitive an action is, the less useful a broad promise of autonomy becomes. Preparing a draft, issuing a document, and sending a communication are separate decisions. A responsible workflow models them separately.

MCP as a tool layer

MCP provides a common protocol for a client to discover tools and pass arguments to them. It does not replace ERP logic or make model output correct by default. The server exposes the contract, the application applies its rules, and the person retains control over changes that require a decision.

Frihet publishes an official MCP server whose current contract contains 157 tools across 17 families, 11 resources, and 10 prompts. The families include clients, invoices, expenses, products, quotes, webhooks, CRM, and other areas recorded in the product manifest.

Tool availability means a programmatic operation exists. It does not mean every client receives access automatically, every field can be inferred, or a result should be confirmed without review.

APIs and webhooks are other parts of the system

Frihet also publishes a documented REST API with API-key authentication. An integration can use it directly when a deterministic flow is required. The webhook system, with 94 event types and HMAC-SHA256 verification, can notify other services about changes.

Each surface has a different job:

• MCP: discover and invoke tools from a compatible client.
• API: run a programmatic integration controlled by code.
• Webhooks: announce events that may start another process.

Combining them still requires workflow design. A webhook does not create a later action by itself; an agent does not receive permission by knowing a tool name; an API key does not decide which operations are appropriate.

A three-level control model

Level 1: read

Initial tasks should be reversible read operations: find a client, list invoices by state, or inspect expenses for a period. Check that the response belongs to the expected account, filters, and dates.

Level 2: prepare

The agent can collect arguments and present a proposal, such as invoice fields, report filters, or draft copy. At this stage it has not changed the primary record. A person reviews fiscal data, amounts, recipients, and context.

Level 3: execute

A write to the ERP, an external send, or an action with financial consequences needs explicit confirmation under the business’s process. The outcome should remain visible, and failures need a correction path.

Example: prepare an invoice without losing control

A request can include a client, description, amount, and date. The MCP client selects a tool and shows the arguments. Before execution, the user verifies client identity, currency, tax fields, and numbering. After the response, they inspect the created record before issuing or sending the document.

This pattern reduces navigation while retaining control at the important points. It does not assume that the AI knows the fiscal context or that connected tools replace professional review.

Checklist for agent-ready software

1. Does it publish a documented API or tool contract?
2. Can authentication be revoked and separated by environment?
3. Does it distinguish reads from writes?
4. Are arguments visible before execution?
5. Does it return structured results and errors?
6. Can a human approval step be inserted?
7. Is there documentation for integrating and stopping the flow?

The agent economy does not require handing a business to an autonomous system. It requires better contracts between people, models, and software. A prepared ERP makes tools explicit, decisions reviewable, and responsibility for data clear.