Agents that act inside your systems of record
Connecting an agent to a chat window is easy. Connecting it to your ERP, CRM, and ledger — safely, observably, and reversibly — is the actual work. That's what we build.
- Typed, scoped action layer
- Idempotent, reversible writes
- Full decision lineage
- Human gates on high-stakes steps
The demo works. The integration is where it gets serious.
An agent that drafts an invoice is a parlor trick. An agent that posts the invoice to your ERP, updates the CRM, and won't double-post when it retries is an integration project.
Systems of record are unforgiving by design. They enforce referential integrity, fire downstream workflows, and assume the caller knows the rules. Point a probabilistic model at that surface without guardrails and you get duplicate orders, orphaned records, and a finance team that no longer trusts the data.
We treat the model as the least-trusted component in the system. Everything it can do is mediated by an action layer that knows your schemas, enforces your policies, and makes every effect observable and undoable. The intelligence stays flexible; the side effects stay disciplined.
How agents touch your systems
Six controls that sit between the model and your production data.
Typed action contracts
Each operation is a schema-validated function — not a freeform API call. The model fills arguments; the contract rejects anything off-shape or out of scope.
Idempotent writes
Every mutating action carries an idempotency key, so a retried or duplicated step lands exactly once. No double-posted invoices, no cloned tickets.
Policy & scope gates
Actions are bounded by role, dollar threshold, record type, and rate. A step above the line pauses for human approval instead of executing.
Decision lineage
Inputs, outputs, model version, authorizing policy, and a correlation ID are logged per call — a replayable trail your auditors can actually read.
Saga & compensation
Multi-system workflows run as sagas. If a later step fails, earlier writes are compensated through the same layer so nothing is left half-done.
Adapters for legacy
No modern API? We wrap SOAP endpoints, DB views, file drops, or screen automation into clean, governed actions the agent can call safely.
From event to committed write
The path a single automated action travels, every time.
Trigger
A source event — a new record, a webhook, a queue message, or a schedule — wakes the agent with scoped context, not blanket access.
Plan
The agent proposes a sequence of typed actions. The orchestrator validates each against schema and policy before anything runs.
Execute
Actions fire idempotently against your systems. High-stakes steps pause for human approval; everything else commits and emits events.
Reconcile
Results are verified against the systems of record, the lineage is written, and any drift or failure routes to an exception queue.
If you can't see it, you can't trust it
Application logs tell you a request happened. They don't tell you that the model chose to issue a refund, which policy let it, and what it read first. Agentic automation needs a different kind of telemetry.
We instrument every workflow with structured traces: the triggering event, the agent's plan, each action's inputs and outputs, the model and prompt version, and the human decisions in between. You get dashboards for cost, latency, and approval rates — and a single switch to pause any workflow or the whole fleet the moment something looks wrong.
- Per-workflow replayable traces
- Cost, latency, and approval dashboards
- Fleet-wide kill switch in under a second
- Drift detection against source data
A raw integration vs. a governed action layer
The difference between a script that works in the demo and one you'd let near the general ledger.
| Wiring a model to your API | An Automatic.co action layer | |
|---|---|---|
| Credentials | Model holds API keys | Brokered, short-lived, per-action scope |
| Bad input | Hits the system, fails loud | Rejected at the contract boundary |
| Retries | Duplicate side effects | Idempotent — lands exactly once |
| Failures | Partial, half-committed state | Compensated and rolled back |
| Oversight | After-the-fact log spelunking | Live lineage, gates, and kill switch |
Frequently asked questions
How do agents write to our systems of record without breaking them?
Agents never touch raw production credentials. They act through a typed action layer that wraps your ERP, CRM, and database APIs — each action has a schema, a scope, and a validation step, so a malformed or out-of-policy call is rejected before it ever reaches the system.
What happens when an integration is mid-transaction and something fails?
Every multi-step write runs as a saga with explicit compensation. If step three fails, the agent rolls back steps one and two through the same action layer, emits a failure event, and routes the exception to a human queue. Nothing is left half-committed in your system of record.
Can we see exactly what an agent did and why?
Yes. Every tool call is logged with its inputs, outputs, the prompt and model version behind it, the policy that authorized it, and a correlation ID that ties it to the source event. You get a replayable decision trail per workflow, not just application logs.
Do you connect to legacy systems that have no modern API?
Often. Where there's no clean API we build an adapter — a thin service over a SOAP endpoint, a database view, a flat-file drop, or screen automation as a last resort — and expose it to the agent as a governed, observable action like any other.
Where this connects
Workflow automation rarely lives alone. These are the pieces it usually touches.
Bring the workflow you don't trust a bot to run yet.
One working session to map the writes, the failure modes, and the guardrails it takes to put an agent into your systems of record safely.