BizFirst TEE — Trusted Execution Environment for Multi-Agent Workflows
Most AI platforms let agents talk to each other. Few ask the harder question: should they trust each other?
At BizFirst, we just shipped a capability we call TEE — Trusted Execution Environment — and it changes how we think about running AI agents inside enterprise workflow automation.
The Problem with Shared Execution
Modern AI workflows are not single-agent affairs. A typical BizFirst process might chain together a data-retrieval agent, a reasoning agent, a compliance-checker agent, and a write-back agent — all wired through our process engine, all running in the same process thread.
When agents share an execution context without boundaries, you get subtle and hard-to-debug problems:
- State bleed. An upstream agent writes something into shared memory. A downstream agent reads it — even if it was never meant for that agent.
- Overreach. An agent has access to the full process context — customer PII, credentials, configuration — even when it only needs a narrow slice.
- No cleanup contract. If an agent fails halfway through, who is responsible for rolling back or releasing what it touched?
- No observability boundary. When something goes wrong, it’s hard to say which agent’s scope the error originated in.
These are not theoretical concerns. In enterprise payroll and financial automation, where BizFirst operates, data mishandling is a compliance event. Overreach is a security incident.
What TEE Does
TEE gives every agent node its own execution scope — a first-class, lifecycle-managed boundary that wraps the agent’s work from start to finish.
When a node has TEE enabled, instead of running directly inside the shared process thread, it runs inside a NodeExecutionScope:
OnBeginScope → ExecuteInternal → OnEndScope
↓ (on exception)
OnScopeException
↓ (always)
Close
The scope carries:
- A unique scope ID — every execution is traceable.
- The root request context — the originating process data, read-accessible to the node builder.
- A scope data bag — a clean key/value store for passing state between lifecycle hooks without touching the shared process context.
Three override hooks give node builders precise control:
| Hook | Purpose |
|---|---|
OnBeginScopeAsync |
Allocate scope resources — open a child DI scope, begin a transaction, log entry |
OnEndScopeAsync |
Commit and finalise — flush output, close resources, log success |
OnScopeExceptionAsync |
Compensate — roll back, alert, emit a telemetry event |
The exception hook never swallows the error — it always re-throws. TEE is about controlled cleanup, not silent failure.
The Design Principle: Opt-Out, Not Opt-In for Agents
A key architectural decision: AI agent nodes default to TEE on.
Every other node type defaults to false — they run in the shared scope unless a developer explicitly enables isolation. AI agents default to true because the risk profile is different. An AI agent makes external calls, consumes tools, and produces non-deterministic output. It earns a boundary by default.
A node builder can still override this per-instance via a single config flag. The default is the safe choice; relaxing it is a deliberate decision.
Why This Matters for Multi-Agent Systems
The real power of TEE isn’t per-agent isolation in isolation (no pun intended). It’s what happens across a chain of agents.
When every agent in a workflow has its own scope:
Least-privilege by default. Each agent receives only what it needs — the RootNodeExecutionContext gives it read access to the originating request, but scope data is private. Agents can’t accidentally read each other’s working state.
Composable rollback. Each scope’s OnScopeException hook is independent. If agent 4 of 6 fails, only agent 4’s scope compensates. Agents 1–3 already committed. Agent 4 rolls back. Agents 5–6 never run. Clean, auditable, predictable.
Per-agent telemetry. Because each scope has a unique ID and a defined start/end boundary, every agent execution is individually traceable in our OpenTelemetry pipeline. You can filter traces by scope ID and see exactly what one agent did, in isolation, with timing.
Extensibility without coupling. The hooks are virtual. A node builder who needs a database transaction wraps OnBeginScope with BEGIN TRANSACTION and OnEndScope with COMMIT. The base class doesn’t know about databases. The database layer doesn’t know about agents. Neither knows about the other.
A Small Detail That Reveals the Philosophy
The scope’s Close() method is internal. Node builders cannot call it. Only the executor framework closes the scope — always, in a finally block, regardless of what happened.
This is intentional. The scope lifecycle is owned by the framework, not by the code running inside it. An agent that throws, hangs, or produces garbage output does not get to decide when its boundary ends. The framework does.
It’s a small design choice. It reflects something important about how we think about trust in agentic systems: the infrastructure enforces the contract, not the agent’s good behaviour.
What’s Next
TEE is the foundation. The hooks are virtual — meaning the next layer up can inject DI child scopes, distributed transaction coordinators, per-agent memory isolation, or remote sandbox execution. The model is in place; the capabilities build on top of it.
For teams building enterprise-grade multi-agent automation — particularly in regulated industries where every action needs an audit trail and every failure needs a clean rollback — this kind of execution boundary is not optional. It’s the baseline.
We built it into BizFirst’s process engine because our customers’ workflows deserve the same rigour as their application code.
BizFirst is building the automation platform for enterprise finance and HR operations. Our process engine powers multi-agent AI workflows across payroll, compliance, and financial operations.