Execution artifacts and the Debugger

Why this exists

An agent's visible output is the last thing it produces. Everything that got it there, the searches it ran, the pages it fetched, the queries it issued, the prompt the model actually received, used to live only in memory for the length of the run and then disappear. When an answer was wrong, there was nothing to look at.

MagOneAI persists that working layer. As an agent runs, its intermediate results are written to the Blackboard: a run-scoped, durable store of artifacts. Those artifacts then do three jobs.

What gets stored

Each artifact is one intermediate result. A short summary and its metadata live in the database; the full body is offloaded to object storage under a tenant-scoped key and fetched on demand. Each row also carries an approximate token size, so you can see what a step actually cost in context.

Identity and re-entry

An artifact is keyed by the step that produced it: the activity, the pass sequence, and the call. That gives two behaviours you want:

• A Temporal retry of the same pass writes to the same key and de-duplicates, so a retried step doesn't double-log.
• A goto re-entry of the same node is a new pass, so it writes a new row. The history of each pass is preserved rather than overwritten.

The Debugger

Open an execution and the Debugger panel gives you the run's glass-box view across three tabs:

Per-step panels

Inside the activity log, an agent step renders two additional panels when the corresponding capture is enabled. Both are scoped to one pass, so a self-looping node shows each pass separately rather than repeating every artifact under every pass.

Prompt sent to LLM. One entry per model round-trip, listed chronologically as LLM call 1, 2, 3…. On a multi-iteration run you can watch the conversation grow as tool results are appended.

Artifacts (N). The step's tool results and captured outputs, each with a kind badge, its label, its token size, and a one-line summary. View full hydrates the complete body.

The action ledger

An agent that re-enters a node starts with a fresh conversation, which means that without help it happily reruns the search it already ran two passes ago.

The action ledger prevents that. At prepare time, the platform builds a compact block from this execution's artifacts, scoped to this one agent, and appends it to the system prompt:

## Actions already taken this run
You have already performed these tool calls in this run. Do NOT repeat an
identical call (same tool + same arguments); reuse the stated outcome or
refine your approach. For the full result of any call, use the blackboard.

- web_search({"query":"Q3 revenue guidance"}) -> Found 8 results; top result is the Q3 earnings release…
- fetch_page({"url":"https://…/q3.html"}) (failed) -> 404 Not Found

• Identical calls (same tool, same arguments) are collapsed to one line.
• The outcome is the artifact's summary, trimmed to 200 characters and flattened to a single line.
• Failed calls are marked (failed), because a failure is information too.
• At most 30 lines are shown, most recent last.
• Non-tool kinds are excluded, so captured agent outputs, saved paths and trajectories never render as phantom tool lines.

The ledger is skipped for chat and free-text agents, and it is best-effort: if it can't be built, the run proceeds without it.

Blackboard recall

The ledger gives an agent a one-line reminder. When it needs the full result of something it already did, it uses the __query_blackboard tool:

{
  "query": "Q3 revenue guidance from the earnings release",
  "top_k": 5
}

• query: what to recall, stated with specific terms and entities.
• top_k: 1 to 10 results, default 5.

The search covers only the current execution's artifacts. The execution id comes from the run context and is never taken from a model-supplied argument, so an agent cannot target another execution or another tenant no matter what it's told to do. If recall is unavailable, it returns empty rather than failing the run.

Recall is exposed per agent through the agent's query blackboard capability, which is off by default, and requires the deployment to have retrieval enabled. When it's on, the platform adds a short nudge to the system prompt so the agent knows the tool is there. Recall is a choice the model makes, not something the platform forces.

The path an agent took

When plan-state persistence is enabled, each agent pass also records its ordered tool-call path: the sequence of calls as they happened, with only consecutive repeats collapsed:

web_search -> fetch_page x3 -> query_table -> web_search

This is a trajectory, not a set: a tool appearing twice at different points appears twice. It answers "what route did this agent take", which a de-duplicated list can't. Saved paths are never indexed, so they stay inspectable without affecting recall.

Captured prompts

The Prompt sent to LLM panel shows the exact request body sent to the model provider, not a reconstruction. It is captured inside each provider adapter immediately before the HTTP request, which has two consequences worth knowing:

• It is the true post-transform payload for that provider: the separated system field, the provider's own message and content structure, converted tool schemas, and any JSON or thinking parameters.
• A failed call still shows what was sent. When a provider rejects a request, the payload is the first thing you want, and it's there.

Every round-trip is captured, indexed by the loop iteration (or structured-output retry), so a multi-step agent yields one entry per call rather than only the opening prompt.

Prompt capture is a standalone capability: a deployment can enable it without enabling the rest of the Blackboard. Captured prompt bodies are retained for 90 days by default, longer than ordinary artifacts, because debugging a bad answer often starts after the report comes in.

Trajectory capture

A trajectory is a canonical, replayable record of one agent pass in ATIF v1.7 (Agent Trajectory Interchange Format), a portable format that external evaluation and training tooling can read directly.

One record contains the ordered steps of the pass (the system step, the user step, one agent step per loop iteration, and the terminal answer) with each agent step's tool calls and their observation results, plus aggregate metrics for the pass and the model or adapter that produced it.

What it's for

Successes and failures are both captured

A successful pass is tagged outcome: success. Failures are captured too, as negatives, with a reason that distinguishes two very different things:

That distinction matters for anyone building a dataset from these: filtering on outcome alone trains against good reasoning that was merely mis-formatted. Filter on the reason.

How observations are stored

Full results are inlined for system, MCP and table-query tools. Results from knowledge-base search, recall and error paths are stored as a 500-character preview and flagged as truncated, but each observation also carries a pointer to its matching tool_result artifact, so the full body can always be hydrated from the Blackboard.

Turning it on

Trajectory capture is off by default and requires three separate opt-ins, because it records production runs:

Once all three are on, every agent pass in that use case is captured, including chat and free-text passes, which are often the most valuable to capture. Trajectory bodies are retained for 90 days by default so a corpus isn't swept before anyone builds a dataset from it.

Retention

Artifacts are hard-deleted on a schedule, both the database rows and the stored bodies, with a per-kind lifetime:

The sweep runs automatically (daily by default) and can also be run on demand by an administrator. Retention exists so that the Blackboard's storage cost stays bounded. It is a hard delete, not an archive.

Tenancy and safety

• Reads are project-scoped. Listing an execution's artifacts and hydrating a body both require the project, enforced at the repository layer.
• Bodies are stored under tenant-prefixed keys that include the organization and project, so a key can't be guessed across a boundary.
• Recall takes its execution id from the run context, never from the model, which closes the obvious injection path.
• Every write is best-effort. Artifact capture, the ledger, recall, prompt capture and trajectory capture all swallow their own failures. None of them can fail an execution. If capture is unavailable, the run completes normally and the artifact is simply absent.

API

Two read-only, project-scoped endpoints back the UI:

Both require project_id. Kind filtering is enforced server-side.

What's enabled by default

Each capability is independently controlled by your deployment, so what you see depends on how your platform team has configured it:

Next steps