Every System Is a Tool: Connecting Agents to Your Stack

The pitch most automation vendors make is rip-and-replace: migrate your data into their system of record, adopt their workflow, and in exchange you get the smart layer on top. It's a bad trade. The system of record is where your operational truth, your audit history, and your compliance posture already live. Nobody wants to re-validate a LIMS or re-implement an ERP integration to get an agent that can read a number off a screen.

Matrix takes the opposite stance. We don't move you off your system of record. We give an agent a fenced, audited window into it — a tool. And the only claim that needs to land for the rest of this post to make sense is this one: an agent tool is just your system, wrapped in a callable. A row in a database, a method on a LIMS, an export from an instrument, a line item in an ERP, a public regulatory dataset — each is one tool definition away from being something an agent can read, reason over, and act on. This is the orchestration-layer thesis made concrete.

Three transports, one tool surface

A Matrix Tool is a generic entity (everything is — see the generic entity model). What makes a tool do something is its transport: how the call actually reaches the outside world. There are three, and the choice is purely about where the capability lives.

• INTERNAL — a built-in the platform ships and runs in-process or in a sandbox: web_search, fetch_url, bash, file_read, file_write, file_list, grep. This is the compute surface. When an agent needs to do something with data — parse a CSV, diff two exports, run a numeric check — it runs code here, not in the model's head. The full story is in the built-in toolbox post.
• HTTP — a single callable function backed by an endpoint you control. This is how almost every internal system gets wrapped: a thin REST surface (yours, or one you stand up in front of a database/LIMS/ERP) becomes a named tool with a typed argument schema. Auth headers are configured per tool and encrypted at rest.
• MCP — a method on an external Model Context Protocol server. When a system already speaks MCP, you don't write a wrapper at all; you register the server as an McpServer entity and its methods join the surface. Both directions of MCP — Matrix as client and server — are covered in MCP both directions.

The important property is that these collapse into one tool surface. AgentToolSurface.composeForCaller unions INTERNAL built-ins, HTTP tools, MCP methods, knowledge search, and memory tools into a single list the model sees per turn. From the agent's point of view there is no "internal system" versus "built-in" distinction — a method that reads your ERP sits next to a sandboxed bash and a web_search, all callable the same way. That uniformity is the four-primitives payoff, and it's what makes "wire up our database" the same shape of work as "give the agent web search."

Wrapping an internal system as a tool

Here's the concrete pattern for turning a system you already run into an agent-callable tool. It's four decisions, and none of them touch the platform's source code — they're all data.

1. Pick the seam. Most internal systems already have some programmatic surface: a query endpoint, a reporting API, a stored procedure behind a small service, a nightly export to a file drop. If the surface is HTTP, you wrap it directly. If it's a database, you put a narrow read endpoint in front of it — one that exposes exactly the queries you want the agent to run, no more. If it's an instrument or a batch system that drops files, the seam is the file: the agent reads the export from the sandbox.

2. Define the schema. A tool's argument schema is its contract. Name the parameters, type them, describe them — { "sample_id": "string", "as_of_date": "string (ISO)" }. The description is not decoration; it's what the model reads to decide when and how to call the tool. A vague schema produces a vague caller. A tight one — with a sentence per argument explaining the domain meaning and the format — produces an agent that asks the system the right question the first time.

3. Configure auth out of band. The tool carries its own credentials. HTTP tools hold headers in headersJsonEncrypted — an API key, a service token, a basic-auth pair — encrypted with the platform master key and never exposed to the model. The agent never sees the credential; it just calls the tool, and the platform attaches the auth at dispatch time. This is the single most important separation in the whole design: the capability is in the tool, the secret is in the vault, and the model holds neither.

4. Read the structured result back. A tool returns data, and the agent's next move is usually to compute over it, not to eyeball it. This is where INTERNAL and HTTP compose: the HTTP tool pulls the records, the sandbox runs code over them. The agent writes the export to a file, runs a script in bash to check each row against a spec, and reads the structured result — pass/fail per field, a trend slope, a flagged outlier — back into its working memory. The model reasons over a computed answer, not a guessed one. Numbers it must not hallucinate get checked by code in a fenced sandbox, then narrated.

Why orchestration beats rip-and-replace

Step back and the architectural argument is simple. When you wrap a system as a tool instead of migrating off it, three things stay true that a migration breaks.

The system of record stays authoritative. No dual-write, no sync lag, no "which copy is right" reconciliation problem. The agent reads the same row your operators read. There is exactly one source of truth, and the agent is a reader of it, not a second writer competing with it.

The integration is incremental and reversible. A tool is a small, named thing you can add, scope, disable, or delete without a data migration. You can connect one report today and a second next week. If a tool misbehaves, you remove it from the agent's surface and the system underneath is untouched. Rip-and-replace has no undo; orchestration is all undo.

The blast radius is a window, not the house. A narrow read endpoint exposes the three queries you sanctioned, not the whole database. The agent's reach into your stack is exactly the set of tools you attached — no more. You're not granting an agent run of your infrastructure; you're cutting a labelled, monitored window into one wall of it.

The honesty guardrails

This is where we get specific, because "agent that touches your system of record" is exactly the sentence that should make a careful engineer nervous. It makes us nervous too, which is why the fencing is structural, not advisory.

Fence the agent to documented data only. The tool surface is the boundary. An agent can call what you attached and nothing else — there's no ambient access to the rest of your stack, no "the model figured out another endpoint." If a query isn't behind a tool, the agent cannot run it. Combine that with the agent's prompt — instruct it to ground every claim in tool output and to refuse to answer beyond what the tools return — and you get an agent fenced to documented, sanctioned data.

Separate read from write. Reading a result and changing a result are different privileges and should be different tools. Most internal-system integrations should be read-only: pull, check, trend, draft. When a write is warranted, it's a distinct tool with its own auth and its own audit trail, attached deliberately — not a side effect of the read tool. Keep the two apart and the common case (an agent that observes and reports) can never accidentally mutate the system of record.

RBAC scopes every call to the caller. Tool dispatch runs under the request's TenantContext and the platform's per-principal access control — the same enforcement every other read and write goes through. An agent acting on behalf of a user inherits that user's scope; an autonomous agent runs under its own scoped principal. There is no tool path that bypasses tenancy or RBAC, because tool calls execute through the same enforced layer as everything else.

The agent interprets, drafts, and flags — a human owns the outcome. This is the line we do not blur. For any regulated or consequential result, the agent's job ends at interpretation: it reads the data, checks it against the spec, trends it, and drafts a document or flags an anomaly. A human reviews and signs. The agent never owns a regulated outcome, and it never silently commits one. It produces a draft and a rationale; the accountable person approves. That's not a limitation we're apologizing for — it's the correct allocation of responsibility, and it's enforced by keeping the write/sign step a human-owned action, not a tool the agent calls unattended.

A worked sketch

Generic, no domain attached. An agent whose job is to keep an eye on a stream of results coming out of an internal system.

1. PULL     → HTTP tool get_results(batch_id) hits a narrow read
              endpoint in front of the system of record; returns
              the latest structured records for the batch.

2. CHECK    → file_write the records to the sandbox; bash runs a
              script that validates each field against the documented
              spec (limits, units, required fields) → pass/fail rows.

3. TREND    → the same script computes the trend across recent
              batches (is the value drifting toward a limit?) and
              returns slope + any out-of-band points.

4. DRAFT    → the agent composes a report: what passed, what failed,
              what's trending, each claim cited to a checked number.
              It flags anomalies for attention. It does NOT release
              anything.

5. SIGN     → a human reads the draft, accepts or edits, and signs.
              The signature — the regulated act — is theirs.

Every number in that report was computed in the sandbox, not produced by the model. Every record came from the system of record through a fenced read tool. The agent's contribution is interpretation and drafting at speed; the accountable decision stays with a person. That's the whole thesis in one loop: the agent is a tireless analyst with a labelled window into your stack — not a replacement for your stack, and not a replacement for the human who signs.

The takeaway

You don't connect an agent to your business by moving your business into the agent's database. You connect it by recognizing that every system you already run is one tool definition away from being callable — HTTP for the things you put an endpoint in front of, MCP for the things that already speak it, INTERNAL for the compute that turns raw results into checked answers. Wrap the seam, type the schema, vault the credential, fence the surface, and keep the regulated act human-owned. The system of record never moves. The agent just gets a window — and you decide exactly how big it is.

If you're staring at a stack you can't and shouldn't migrate, that's not a reason an agent can't help. It's the reason orchestration exists.