II · Planning & Control FlowEmerging★

Decision Context Maps

also known as Pre-Decision Context Gathering

Before any consequential decision, require the agent to gather a declared set of contextual inputs (resource availability, schedules, downstream dependencies) into a 'context map' the decision must cite.

Context

An agent makes consequential decisions (production routing, treatment plan, capital allocation). Default behavior is to decide from the immediate prompt context plus whatever the model 'thinks' it knows — which routinely misses out-of-prompt operational state.

Problem

Decisions made without gathered context cascade errors downstream — the agent routes production assuming a machine is available that is actually down for maintenance; it schedules a treatment forgetting a contraindication in a record it never queried. The error is invisible at decision time because the agent lacks the relevant input it did not bother to gather.

Forces

  • Gathering all possibly-relevant context for every decision is expensive.
  • Context schemas must be designed per decision class; one size does not fit all.
  • Some context sources (legacy systems, slow APIs) add real latency.

Example

A manufacturing-routing agent is asked to route a new production order. The 'production-routing' Context Map schema requires: machine availability, maintenance schedule, worker shift roster, downstream-line capacity, current WIP queue depth. The agent queries each, populates the map. If any required entry comes back null or stale, the decision is held and a human is paged. With Context Maps in place, the cascading-routing-error rate drops sharply.

Diagram

Solution

Therefore:

For each decision class (production-routing, treatment-plan, etc.), publish a Context Map schema: list of required inputs (data sources, who/what to query, freshness requirements). At decision time the agent populates the map — querying APIs, checking schedules, retrieving records. The decision step receives the populated map as input and cites entries when justifying its choice. Pair with strategic-preparation-phase (which contains Context Maps for one-off problems), policy-as-code-gate.

What this pattern forbids. No decision in a declared decision class may commit without a fully-populated Context Map; missing required entries fail the decision, not the agent silently proceeding.

And the patterns that stand alongside it, or against it —

  • complementsStrategic Preparation Phase★— Mandate an explicit problem-space representation step before the agent attempts solutions, mirroring how expert humans build a mental model of constraints and dependencies before solving.
  • complementsPolicy-as-Code Gate★— Evaluate every proposed agent action against externally-managed machine-readable policies before dispatch, so compliance authorship lives outside the prompt and outside the agent code.
  • complementsAgent Evaluator★— A dedicated agent or harness whose sole job is running tests against another agent's outputs to evaluate performance; distinct from eval-harness (offline batch) and llm-as-judge (per-output).
  • complementsDecision Log★★— Persist the agent's reasoning trace alongside its actions so post-hoc review can explain why.
  • complementsPolicy-Gated Agent Action (KRITIS)★— Each agent action passes through a policy gate (NIS2, EU the agent Act, BSI rules) and is tagged with Run ID + Model Digest + Policy Hash for WORM-audit reconstruction.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

References

Provenance