Foundation models are not the product

Foundation models can be isolated as replaceable inference components within an enterprise architecture. A shared API does not make their operational behavior interchangeable; that has to be measured on paired job runs. Model quality and cost still matter, but neither determines by itself whether a workflow is safe, recoverable, and complete.

The difficult engineering work begins after inference: translating a proposed action into a correct transaction on a live ERP and the systems around it. NetSuite, SAP, and Dynamics expose different schemas and operating assumptions. The execution layer has to preserve state, enforce policy, and finish the workflow despite those differences.

For an execution workload, the unit of work is the resulting system change: issued under the correct identity, supplied with valid parameters, checked against the system of record, and recoverable after partial failure. A plan or transcript may support that process, but it is not evidence that the transaction completed.

Where generic agents fail

Blank-slate agents often concentrate too much responsibility in the foundation model. Tool selection, context, policy interpretation, and recovery all become prompt behavior. Synthetic function-calling tests can measure argument generation, but they do not cover a tenant’s item master, approval chain, posting rules, or partially committed workflow.

A vendor may be represented as a NetSuite entity, an SAP business partner, a Dynamics account, and a contract counterparty, while only one record reflects the terms that govern today’s purchase order. The model can interpret those records, but the execution layer must identify the authoritative source before it writes.

A model change should not alter the tool sequence, validation gates, or completion criteria for the same job.

Five layers that survive a model change

In EGI’s architecture, neural inference parses messy inputs and proposes intent. Symbolic execution converts that intent into typed, rule-bound actions against enterprise APIs. Reliability comes from the state, execution, evaluation, and control mechanisms that remain stable when the inference model changes.

• Context graph — continuously refreshed enterprise state across structured and unstructured systems, with dynamic addition, updating, and eviction of context.
• Execution graph — learned mappings from intent → tool sequence → validation → recovery → completion across real enterprise workflows.
• Feedback + eval layer — production traces, human corrections, failure modes, and edge cases that raise execution accuracy, not demo fluency.
• Pre-trained enterprise execution — reusable role and workflow patterns learned across real ERPs, so the agent does not arrive as a blank slate.
• Control plane — permissions, approvals, observability, auditability, and policy enforcement required for safe autonomy.

Together, these layers let the same purchase-order or close specification run against a different foundation model while retaining its operational pass criteria: correct entity, authorized amount, complete audit trail, and closed job.

Bruce is the enterprise execution agent

Bruce is EGI’s enterprise execution agent. ERP workflows—purchase orders, receipts, journals, and close—are the canonical workload because an incorrect write can affect inventory, cash, or the company’s books. The same execution controls also support adjacent surfaces such as revenue operations.

Standardized jobs-to-be-done define the expected outcome. Pre-trained execution patterns provide a starting point, and production evaluations establish readiness on unlike tenant stacks. Bruce packages those elements into a deployable execution agent while keeping the foundation model as a replaceable dependency.