Event-driven execution

Alquimia Platform’s execution engine is event-driven. Every action the agent takes — calling an LLM, executing a tool, flushing memory — is represented as a typed command or response that is emitted, dispatched, and consumed by the controller.

Commands and responses

Events are split into two categories:

Commands express intent. They are emitted by the controller stages when work is needed:

Command	Purpose
AssistantInference	Start a new inference run
ResponseInference	Call the LLM with the current conversation
ShieldInference	Run a guard or classifier model
ServerToolExecution	Execute a tool on an MCP or Llama Stack server
ClientToolExecution	Ask the client application to execute a tool
A2AInference	Delegate to another agent
ToolSchema	Discover tool schemas from a tool source
AgentDiscovery	Discover available agents from the registry
HumanApprovalRequired	Request human approval before a tool runs
ContextFlush	Trigger long-term memory summarization
ContextPersistence	Persist the current conversation state

Responses describe what happened. They are produced by handlers and consumed by the stages:

Response	Purpose
AssistantInferenceResponse	Final answer — terminates the loop
ResponseInferenceResponse	LLM call result
ShieldInferenceResponse	Guard model result
ToolExecutionResponse	Tool execution result
ToolSchemaResponse	Tool schema discovery result
AgentDiscoveryResponse	Agent discovery result
HumanApprovalRequiredResponse	Human approval decision
ContextFlushResponse	Memory summarization result
EmpathyRuleMatchedResponse	An empathy rule changed the response profile

Correlation and the worklog

Every command carries a unique control identifier. The corresponding response carries the same identifier. This lets the controller match responses to commands and resume the pipeline in the right place.

The worklog is an append-only log of all events processed during a single inference run. It serves three purposes:

1. State reconstruction — the controller can inspect the worklog to decide what to do next.
2. Audit trail — every step is recorded for compliance, debugging, and replay.
3. Response matching — pending commands are paired with their responses as they arrive.

Event flow example

A single inference with one tool call might flow like this:

AssistantInference
      │
      ▼ (Preprocess)
ShieldInference ────────────► ShieldInferenceResponse
      │
      ▼ (Process)
ToolSchema ─────────────────► ToolSchemaResponse
      │
ResponseInference ──────────► ResponseInferenceResponse (tool call requested)
      │
ServerToolExecution ────────► ToolExecutionResponse (tool result)
      │
ResponseInference ──────────► ResponseInferenceResponse (final text)
      │
      ▼ (Answer)
ContextFlush ───────────────► ContextFlushResponse
      │
ContextPersistence
      │
      ▼
AssistantInferenceResponse

The loop continues until the agent produces a final response or reaches a configured limit.

Replay and recovery

Because the worklog records every event in order, an inference run can be reconstructed or replayed. This is valuable for:

• Debugging — see exactly which tools were called and what the LLM returned at each step.
• Compliance — prove what the agent did and why.
• Testing — replay a recorded run against a new agent version to detect behavior changes.

Observability

Every event that passes through the execution loop is observed by the platform’s telemetry layer. Metrics are tagged with the same identifiers used by traces and logs, so you can correlate a metric spike to a specific trace and its log records.

Related pages

• Architecture — how the controller processes events
• Agents & configuration — the agent spec that drives events
• Observability — how events feed metrics, traces, and logs
• Auditability & compliance — the worklog as an audit trail