AI Context Harness: Load, Update, and Check Agent State

An AI context harness is the wrapper code that loads context before an agent runs, updates a shared state store while it works, and checks the result when it stops. Without it, each agent run starts from scratch and leaves nothing behind.

Getting this right matters most in multi-session and multi-agent workflows, where the context from one run becomes the starting point for the next. Tools like fenbs act as the persistent work state the harness reads and writes: tasks, rules, and Where we left off, available to any connected agent, in any session. Context compression, context-aware AI, and context engineering are covered on their own pages.

The three moments in a context harness

A context harness has three distinct jobs, each at a different moment in the agent lifecycle.

• Load: before the agent runs, assemble the context it needs. This includes the task description, approved rules, prior progress, and any relevant notes. Keep the context focused: too much context dilutes the important parts.
• Update: while the agent works, write checkpoints and intermediate results to the persistent store. Do not wait until the end — a run that fails midway should leave the state better than it found it, not unchanged.
• Check: when the agent stops, verify that the output matches what was expected and that the state store reflects what actually happened. Catch mismatches at the boundary.

Loading context before the run

A context load has a priority order. Start with rules and constraints — the things the agent must know before anything else. Then the current task: what it is, its plan, and where it stands. Then the prior progress: what was completed, what was checked, and what is waiting for a person.

Do not load everything. An agent that starts with fifty notes, a full decision history, and a complete chat log has to parse all of it before it can act usefully. Pick the context that changes the next action: the relevant rules, the active task, and the last progress note.

For repeatable context loads, define a context schema: a typed structure that specifies which fields the agent receives and in what order. A schema makes the load testable and makes it clear when a field is missing versus empty.

Updating state during the run

Write to the state store during the run, not just at the end. An update after each significant step means a failure midway leaves the store in a recoverable state, not an empty one.

Each update should record what changed and why, not just the new value. "Task moved to In Progress because the agent began work on step 2" is more useful than a status change with no explanation. The explanation is what the next agent needs to understand the state without replaying the run.

Separate fast, volatile updates from durable writes. A count of tokens processed is a volatile metric that does not need to be written to a durable store. A completed step that a person or another agent will rely on does.

Checking state after the run

A post-run check has two parts. First, validate the output against the expected schema. If the agent was supposed to produce a structured JSON object and returned prose, catch that before anything downstream reads it.

Second, verify that the state store reflects the run. If the agent claimed to complete step 3, is step 3's completion recorded with evidence? If the agent created an external artifact, is the artifact reference in the store? A state store that diverges from what actually happened is worse than an empty one, because it misleads the next agent.

Also check for waiting states. If the agent stopped because it needs a person's decision, is that request visible somewhere a person will see it? A waiting state that is not surfaced is a silent stop.

Memory updates in a multi-agent context

When multiple agents share a state store, writes must be attributed and ordered. An agent that writes a value without recording when it wrote it and under what conditions leaves the next reader with no way to evaluate freshness.

Use optimistic concurrency for low-contention updates: read the current value, check a version field, write the update with an incremented version. If two agents write concurrently, one will fail the version check and retry. For high-contention writes, use explicit locking at the task level.

The AI context window guide covers how context length and composition affect what an agent can reason about reliably. The context engineering guide goes deeper into what to load and how to structure it.

How to do this with fenbs

1. Create a free account and add your project in fenbs with the tasks and rules the agent harness will read.
2. Connect your AI assistant from Integrations using MCP. The harness calls fenbs MCP tools to load context: rules first, then Where we left off, then active tasks.
3. As the agent works, update tasks in fenbs after each significant step. Record what was completed, what was checked, and whether a person's input is needed.
4. Before the run ends, call the save-progress tool. Record the task's current state and the project's where-we-left-off so the next session starts correctly.
5. After a run that revealed a gap in the context, update the relevant task notes or add a context note to the project. The next agent will read the improved context.

fenbs does not manage in-memory, per-request context assembly — that belongs in your harness code. It holds the persistent work state that outlasts any one run: tasks, rules, decisions, and progress.