An operations agent rarely begins with a question. It begins with something happening.
A shipment misses a scan. An invoice total does not match the purchase order. A loan application arrives without one of the documents used by the review team. The work starts because an event has entered the operation and somebody now needs to decide what happens next.
That is why the central abstraction in Proxima is not a chat session. It is a path from event to action.
Source systems Operational context Decision Action
TMS ───────┐ Carrier ───┼──> Event layer ──> Case ──> Decision engine ──> Proposal ──> Execute CRM ───────┤ │ │ Email ─────┘ └──── New events ←──── Outcome ─────┘
The arrows in this diagram look linear. A real case is not. New events can arrive while an action is waiting, an outcome can reopen a case, and an execution failure can send the workflow back for another decision. The runtime has to preserve that history without losing the current state.
One event, several systems
Consider a priority shipment whose ETA has moved beyond the promised delivery time. The carrier knows the latest ETA. The order system knows the promise made to the customer. The CRM knows whether the account is strategic. The TMS may be the place where an exception is eventually opened.
No single record contains the decision.
Before Proxima can propose anything useful, it must bring those facts into a stable shape. Every event needs a unique identity, a source, the time it happened, the time it arrived, and a way to connect it to the operational case. Source details remain attached so an engineer can trace the event back to the record that produced it.
The correlation ID matters as much as the payload. Events arrive one at a time, but operations happen as cases. A delayed ETA, an address correction, and a carrier response may all belong to the same shipment. Without correlation, the agent sees three isolated messages instead of one changing situation.
Normalize before deciding
Source data should not leak into business logic.
If one TMS uses promised_date, another uses delivery_commitment, and a carrier webhook sends expected_delivery_at, rules should not contain three versions of the same idea. Proxima maps source fields into the workflow’s canonical payload and keeps the original source details for lineage.
The workflow then computes derived facts. Two timestamps become eta_delay_minutes. Customer tier and shipment value may become a risk band. These values are calculated once, named in business terms, and reused across the decision path.
This layer looks ordinary, but it removes a large class of production failures. It stops each rule, prompt, and integration from inventing its own interpretation of the same field.
Make the decision inspectable
The current Proxima runtime core evaluates the normalized event against the selected workflow pack. It records every rule evaluated, the rule that won, the derived facts used, and the resulting recommendation.
A recommendation is not yet an action. It says what the workflow believes should happen and why. For a serious delay on a high-value shipment, that may be escalate_priority_case, with the calculated delay, classification, severity, and confidence attached.
Keeping the decision separate from execution is intentional. It allows the same decision to be replayed, reviewed, compared, or routed differently without running the external action again.
The alternative is to let decision logic call tools directly. That is convenient in a prototype, but it couples reasoning to side effects. A replay can accidentally repeat an action, a model change becomes an integration change, and a failed tool call obscures whether the underlying decision was sound. Proxima puts a durable proposal between the two.
Turn a decision into an action proposal
The next contract is an action proposal. It translates the workflow’s recommendation into something the runtime can track.
An action proposal includes:
- The event and decision that produced it
- The action key and action type
- The intended target and payload
- Risk and confidence
- A plain explanation and supporting evidence
- Its current lifecycle status
The proposal might result in a notification, escalation, hold, recommendation, or system update. At proposal time, the runtime does not pretend the work is complete. It has only established an intended action.
Execution is a lifecycle
External systems fail in unhelpful ways. Requests time out after succeeding. Credentials expire. A target record has changed since the event arrived. One of two related calls works.
For this reason, Proxima models action status explicitly. The first runtime slice supports proposal, review, approval or rejection, escalation, mock execution, and failure. Production execution extends that lifecycle with adapter-specific results, retries, and reconciliation.
Idempotency is essential here. Retrying a customer notification may be harmless; retrying a refund or inventory movement may not be. The runtime needs a stable execution key and a record of previous attempts before an adapter can decide whether a retry is safe.
There is another complication: an external timeout is ambiguous. It can mean that the target did nothing, or that it completed the action and the response was lost. The adapter may need to check the target system before retrying. This is one reason execution policy belongs with the action adapter rather than inside a general-purpose model instruction.
Close the loop with outcomes
The event-to-action path is incomplete until the result returns.
Did the shipment recover? Did the customer respond? Did the case reopen? How long did resolution take? These outcome events attach to the same case and allow the team to judge the workflow on operational results, not just whether an API returned 200.
Over time, those outcomes become the evaluation set for the next workflow version. A changed decision policy can be replayed against previous cases. A model update can be compared with the version it would replace. A new action policy can be tested before it touches a live system.
This closes an important design loop. Recommendation agreement is useful during development, but an operation ultimately cares about resolution time, service recovery, error reduction, cost, or another business result. The runtime must retain enough context to connect the action with that later outcome.
The runtime is the reusable product
Shipment recovery is one workflow. Invoice matching or application triage is another. Their fields and decisions differ, but the mechanics are the same: receive the event, establish its context, derive the facts the workflow needs, make a decision, propose and execute an action, and observe the outcome.
Proxima implements those mechanics once. Workflow packs carry the domain meaning. Adapters carry the system-specific behaviour. The runtime joins them and preserves the history of what happened.
That is the difference between an agent demonstration and an operational product. The model may help make a decision, but the runtime makes that decision usable.