Agent Workflow State

Summary

Lux Sync can expose live state from agents, workers, jobs, and automations to users or supervisory systems. An agent publishes compact progress state; browsers or services subscribe and follow the job in real time.

Buyer phrase: “I have agents or workers doing background tasks, and I need users or operators to see what they are doing right now without building a dedicated realtime service.”

Buyer Problem

Agentic and workflow systems often need to report current state:

• queued;
• planning;
• fetching data;
• validating;
• waiting on user input;
• retrying;
• complete;
• failed.

The buyer may already have durable job storage, but the UI still needs a fast live projection. Polling job status is wasteful and can feel sluggish. Lux provides the live state layer.

Lux Architecture

An agent, workflow worker, or orchestrator publishes job state to a Lux document. A UI or supervisor service subscribes to the same document.

Data path:

1. Agent starts a job.
2. Agent writes step, progress, summary, and optional diagnostic fields to Lux.
3. Lux stores the active state in memory.
4. UI receives changes over WebSocket.
5. Durable job history remains in the buyer’s existing workflow system if needed.

Example State

{
  "job": "invoice-reconcile",
  "step": "validating",
  "progress": 67,
  "actor": "agent-1",
  "summary": "invoice-reconcile validating 67%"
}

Implementation Shape

Use one document per job, run, session, or workflow:

agent-run-20260617-001
workflow-invoice-reconcile-abc123
session-agent-support-4921

Agent update:

curl -X PUT "$BROKER/api/lux/workflow-invoice-reconcile-abc123" \
  -H "Authorization: Bearer $LUX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"data":{"job":"invoice-reconcile","step":"validating","progress":67}}'

Browser supervisor:

const run = lux('workflow-invoice-reconcile-abc123', {
  endpoint: `${broker}/api/lux`,
  websocketUrl: `${wsBroker}/api/lux/stream/workflow-invoice-reconcile-abc123`,
  apiKey,
  realtime: true
});

await run.load(renderAgentProgress);

AWS Estate Proof

Scorecard: /mnt/data/ubuntu_data/code/lux/artifacts/usecase-scorecard-aws/20260617T221800Z/scorecard.md

Proof string: invoice-reconcile validating 67%

Result:

• CLI proof: PASS
• Browser Playwright proof: PASS
• PUT ack observed from external operator machine to AWS EC2: 157.498 ms
• WebSocket delivery observed from external operator machine to AWS EC2: 396.208 ms

Timing boundary: this external AWS estate timing includes public network latency.

Customer Data Handling

For buyer-deployed brokers, agent workflow state remains in the buyer environment. Voxell does not need to receive the agent’s task state, prompts, documents, intermediate outputs, or customer payloads.

Good Fit

Use Lux for:

• visible progress for AI agents;
• live background job status;
• worker heartbeat and current step;
• user-facing automation progress;
• supervisor screens for agent fleets;
• “waiting for input” state.

Poor Fit

Do not use Lux alone as:

• a durable workflow engine;
• a job scheduler;
• a guaranteed retry system;
• a long-term job history store;
• an audit trail for regulated agent actions.

Lux should publish the current state while the buyer’s workflow engine or database remains the durable source of truth.

FAQ

Can agents publish state directly to Lux?

Yes. An agent or worker can write JSON state to the broker using the HTTP API. UIs and services can subscribe to the same document over WebSocket.

Does Lux store the full agent transcript?

Not by default. Lux synchronizes the current state payload the buyer sends. Buyers decide whether to include summaries, progress values, small outputs, or references to durable records.

Can this work with multiple agents?

Yes. Use one Lux document per job, agent run, session, or shard. A supervisor UI can subscribe to the relevant documents.

Is Lux the workflow system?

No. Lux is the live state broker. The durable workflow system, retry logic, and history can remain in the buyer’s existing application.