The execution graph

Many products use “execution layer” to describe orchestration: nodes, state objects, checkpoints, and human interrupts. These are necessary control-flow primitives. They do not specify which transaction is correct, how it should be validated, or what completion means for a particular function and tenant.

The harder problem is mapping intent to a finished job on systems that were not designed to be driven by a model. A developer-defined sequence provides an initial path, but production execution also requires tenant-specific validation, recovery, and completion criteria. Those behaviors should remain stable when the inference model changes.

Intent → tools → validation → recovery → completion

EGI’s execution graph is that mapping, earned on real workflows rather than invented in a demo harness.

• Intent — what the job is, including what must not be done. A revenue job is not a finance job. The spec is function-specific.
• Tool sequence — which APIs, in which order, with which parameters, on this tenant’s stack. Wrong tool and right tool with wrong args are both failures.
• Validation — the write is checked against the system of record and the job spec, not against the model’s confidence.
• Recovery — partial failure is the default in enterprise software. The graph includes the retry, the compensation, the escalation—not an exception handler added later.
• Completion — the job is closed to a defined expectation, with an audit trail. A paused chat is not a completed run.

Generic agents often implement tool selection without equivalent mechanisms for validation, recovery, and completion. A successful call may end the trace even when the broader job remains incomplete. This gap tends to emerge only after deployment, when partial failures and tenant-specific exceptions become routine.

Pre-trained, then tenant-bound

Pre-trained enterprise execution initializes the graph with reusable functional patterns: how a signal becomes a purchase order, how a close workflow clears exceptions, or how a prospect becomes an engaged opportunity. Tenant binding then maps those patterns to local systems, identity, policy, and completion criteria.

The neuro-symbolic boundary separates interpretation from commitment. Neural inference handles ambiguous input; symbolic code generation applies typed constraints to the resulting action. The execution graph connects those stages across tools, checkpoints, and recovery paths. Its behavior should remain testable when the inference API changes.

Bruce runs this execution graph across ERP and adjacent operational workflows. ERP is the canonical production surface; revenue is another function using the same state, validation, and control mechanisms.

When we score a run, we are scoring the graph: goal persistence, tool execution, multi-step completion, state, error recovery, outcome quality, constraint adherence. A model leaderboard cannot see any of that. A posted journal on a live ERP can.