ECOSIRE platform

What is Agentic ERP?

Agentic ERP is an ERP in which AI agents are first-class accounts rather than a chat window. An ECOSIRE agent has its own record with an explicit list of tools it may call, a maximum risk level it may act on without a human, and an hourly action limit. Every action it attempts follows one path — propose, policy check, approval where required, durable execution, ledger entry — and no agent write can bypass that path. Actions rated critical, such as posting a journal entry or registering a payment, require a person at every autonomy level, including the highest.

Policy: 110; low · medium · high · critical
The autonomy ladder: 3; L0 · L1 · L2
Connect your own agents over MCP: POST /api/mcp; eco_live_…

The one path every agent action takes

There is no second route. An agent cannot write to the database directly, and a tool cannot be called out of band — the gateway is the only door, and it is the thing that writes the ledger.

Propose
The agent names a tool and supplies its arguments. An unknown tool name or arguments that fail the tool's schema are rejected outright, before any ledger entry exists — the ledger records decisions about valid proposals, not malformed calls.
Policy
Three checks can deny outright: is the agent active, is this tool on its allowlist, and is it inside its hourly action budget. A denial on any of them is written to the ledger with the reason. A fourth check is not a denial — if the tool's risk rating sits above the agent's ceiling, or is rated critical, the proposal is routed to a human instead of refused.
Approve
Anything above the agent's ceiling — and anything rated critical, always — lands in an approvals inbox as a pending proposal and posts a note to the record's timeline. A person approves or rejects it, and their identity is stored with the decision.
Execute
Approved work goes onto a durable queue under an id derived from the action, so a retry cannot double-run it. The worker re-checks that the agent is still active and the tool still exists before it touches anything, and a job that dies mid-flight is reaped rather than left stuck.
Ledger
Success or failure, the outcome is stored with the decision reason — and, where a model was involved, the model and prompt version, the tokens consumed and the cost in integer micro-dollars, never a float. Entries are not edited or soft-deleted in normal operation; removing an agent account removes its history with it. Export as JSON for the complete record, or CSV for the decision fields. The record's timeline gets the result too, so the people who work that record see what the agent did without opening an admin screen.

The autonomy ladder

One dial per agent, three positions. What the dial actually sets is a single number: the risk level above which a human must approve. Start every agent at L0, read its ledger for a week, then decide whether to raise it.

The autonomy ladder	Approve
L0 Suggest	auto-executes up to none
L1 Assist	auto-executes up to low
L2 Operate	auto-executes up to high

No level maps to a critical ceiling, because critical never auto-executes. The highest selectable level is L2 — raising the dial widens what runs unattended, it never removes the approval requirement on critical actions.

Connect your own agents over MCP

POST /api/mcp implements the Model Context Protocol over stateless streamable HTTP. Authenticate with an agent key issued from the admin console — the raw key is shown once — and the server lists the business tools on that agent's allowlist, plus four built-in controls for reading action status and driving loop runs. Nothing outside the allowlist is offered. A tools/call goes into the same gateway as our own agents: the same policy checks, the same approvals inbox, the same ledger. GET is answered 405 on purpose; MCP here is POST only.

A worked example: the collections agent

It is opt-in per organisation: no collections agent account, no scan. Every morning it reviews overdue invoices and proposes one dunning message per invoice at the 7-, 14- or 30-day mark, keyed so a second scan the same day cannot duplicate it. Below L2 it cannot send at all — the proposal sits in the approvals inbox. Sending is gated on the suppression list, and an error in that gate means do not send. Proposing a payment reconciliation is rated critical, so it is a proposal forever, at every level.

What stops an agent going wrong

An agent key is walled off from every user-key path, so it can never act as a person. Every query is scoped to your organisation in application code — that is the primary control; database row-level security is provisioned on the core business tables and still runs fail-open while it is rolled out, so treat it as defence in depth rather than the thing holding the line. Suspending an agent stops it at the gate and mid-flight: the executor re-checks that it is still active before running an already-approved action. Outbound messages fail closed against the suppression list. Unattended loop runs additionally have a kill switch — one flag for the whole fleet, one field per agent.

Want to see it against your own data?

Tell us which process you would put an agent on first, and we will walk it through the ladder with you — starting at L0, where it proposes and executes nothing.