Who Fires the Agent? Why Four Agent Runtimes Means Zero Accountability

The dominant agent strategy in enterprise software right now is to not run the agent at all. Process-intelligence vendors have repositioned around agentic AI, but their architecture gives away what they actually do: they observe your processes and feed context to agents that execute somewhere else.

One market leader packages this as a meta-orchestration layer over agents built across four different third-party runtimes — a chat-agent builder, an enterprise agent orchestrator, a cloud model platform, and an open-source agent framework. Read that list again. That is four separate control planes, four permission models, and four runtimes, marketed as openness. Another vendor splits the same problem a different way, distributing context, build, and inventory across three separate tools in its own suite. That same vendor has even raised the question of who ultimately "fires the agent" — and its own split architecture is precisely what leaves that question unanswered.

None of this is presented as a compromise. It is the recommended blueprint. It is also why the systems integrators are so pleased: the seams between four vendors are billable forever.

Every runtime you assemble into a working agent brings its own governance model. Stitch build, inventory, context, and execution across four tools and every join between them becomes a governance discontinuity — a place where a policy is translated, re-implemented, or simply dropped.

Trace a single autonomous action through that topology. The agent's authority is granted in one vendor's console. Its decision is orchestrated in a second. The work touches your systems of record through a third. The record of what happened is written — partially — in all of them. No single log is authoritative. No single owner enforced, executed, and recorded the action end to end. When you need to reconstruct what the agent was allowed to do at the moment it acted, you are correlating timestamps across four exports.

That is the accountability gap in one sentence: accountability spread across four vendors belongs to no one. And it drifts. Entitlements granted in the agent-builder tool and enforced nowhere downstream go stale; a threshold tightened in one tool is invisible to the runtime that actually executes; the identity the agent uses to write to the ERP is not the identity that reasoned about whether it should. Each seam is a standing liability that no one vendor is contractually on the hook for.

There is an architectural tell underneath all of this. Process intelligence is a system of observation. It reconstructs your process from batch-extracted event logs — a picture of what already happened — and then hands the resulting context to an agent that acts elsewhere. Observe, recommend, hand off.

The consequence is structural, not incidental. The event logs are extracted on a schedule, so the agent reasons over a reconstruction that is already minutes or hours stale. And the moment of action leaves the system that understood the process entirely. Governance can only be a report written after the fact, never a gate at the instant the action is attempted. By the time a violation surfaces on a dashboard, the payment has cleared.

Contrast the shape below the line: observe, decide, act, govern — closed inside one runtime, on live authoritative state. The system that sees the process is the system that acts on it, so policy can be a hard gate at the moment of action rather than a post-mortem on what already went wrong.

Entroid models every process as a composition of five primitives on one semantic ontology, and — this is the part that matters — executes and governs them in a single runtime. That design is what gives the question an answer.

• Intelligence Orchestration owns agent authority and permissioning. Authority granted in one place can be revoked in one place. That is what firing an agent mechanically means: there is a control plane with the standing to say no, and to narrow or withdraw an agent's remit the instant policy changes.
• Deterministic Workflows enforce governance inline. Approval gates, segregation of duties, entitlement and authority limits, thresholds, and human-in-the-loop checkpoints live on the path itself — so a non-compliant action is impossible to execute, not merely reported after it clears.
• Atomic Agents do the bounded work at the leaf. Human-in-the-loop is first-class: pause, surface the reasoning, incorporate feedback, resume — always inside the authority the orchestration layer set.
• Connectors are the only primitive that touches external systems. Every read and write to a system of record passes through one governed, authenticated, rate-limited, audited door.
• One immutable audit trail binds every agent decision across all five primitives — a single authoritative record, not four partial ones you reconcile after the fact.

Underneath sit the platform capabilities that make the record trustworthy: durable long-running process state, versioning of in-flight instances, compensation and rollback when a step must be unwound, and configurable exception handling and escalation. The trail is not a log stitched together later; it is the runtime's own memory of what it enforced.

This is the honest version of the word "autonomous." An agent is autonomous here because a single runtime enforces the limits it operates inside and can revoke its authority in one action — not because it has been let loose across four platforms that no one fully controls.

Consolidation usually gets pitched to a CIO as procurement math — fewer contracts, fewer integrations, lower total cost. That undersells it badly. On one fabric, the reason to consolidate is that a single system enforced, executed, and recorded the action, which means a single owner can answer for it. Fewer vendors is the invoice. One accountable runtime is the point.

Consider a payment-posting agent — illustrative, not a delivered result — that attempts to clear an invoice above its authorized limit. In the rented model, the threshold check lived in one tool, the execution in another, and the log in a third; establishing what was permitted, and precisely when, becomes forensic archaeology across vendors while the money has already moved. On the fabric, the entitlement limit is a hard gate in a Deterministic Workflow: the action simply never executes. If the policy itself was wrong, Intelligence Orchestration narrows the agent's authority immediately, and the immutable trail shows exactly what was allowed, by whom, and at what version of the process. One place enforced it. One place can change it. One place has to answer for it.

For the CISO and the risk officer, that collapses the entire agentic-AI control question into something auditable. There is one identity boundary, one entitlement model, and one record to examine — not a distributed system whose failure modes live in the gaps between four control planes you do not operate.