How One Agent Can Track Drift While Another Agent Implements

When two AI agents work on the same project, the risk is not only that one of them makes a mistake. The larger operational risk is drift: the implementing agent starts moving away from the requested scope, the reviewer loses the exact handoff context, or both sessions silently disagree about what "done" means. AxiOwl does not solve that by pretending to read intent or automatically detect semantic drift. The useful pattern is more practical: keep the implementing session and the tracking session separate, move instructions between them as explicit messages, and make every handoff leave receipts and logs that an operator can inspect.

That is the difference between "two chats talking" and a controlled multi-agent workflow.

Sources read

• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\docs\reference\architecture-overview.md
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\docs\developer\README.md
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\docs\user\README.md
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\docs\PLAN-SIMPLE-AXIOWL-APP-ARCHITECTURE.md
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\models.hpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\message_pipeline.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\final_visible_body_builder.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\mcp_server.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\cli.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\delivery_worker.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\registry.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\evidence_log.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\src\app_paths.cpp
• C:\Users\kjhgf\OneDrive\Documents\postfourth\axiowl-cplus\apps\windows-desktop\tests\core_tests.cpp

The drift-tracking role

In an AxiOwl workflow, a drift-tracking agent should not be the same session doing the implementation. The implementer needs room to edit, test, and recover from local details. The tracker needs a stable view of the original request, the current acceptance criteria, the receipt IDs, and the actual replies coming back from the implementer.

A simple operator split looks like this:

• Implementation agent: receives the scoped task and performs the code or content work.
• Tracking agent: watches whether the work still matches the requested scope, asks for status, requests evidence, and flags any mismatch.
• Human operator: decides whether a drift warning matters and whether to redirect, pause, or accept the work.

AxiOwl supports that split because its core model is explicit. The project docs describe the contract as one sender, one target, one body, one provider edge, and one receipt. The registry maps human-readable agent names and aliases to provider sessions, provider session IDs, node IDs, and sendability. That matters because drift tracking depends on knowing which session was asked to implement and which session is auditing it. A vague chat title is not enough.

Send the scope, then send the audit

The usual command shape is intentionally small:

axiowl send --to "Implementation Agent" --body "Implement the requested change. Keep the scope limited to the named file and report the tests you ran."

For longer instructions, the documented pattern is stdin:

@'
Update the provider routing code for the named issue.
Keep the change limited to the routing layer and its focused tests.
Do not edit installer packaging or unrelated discovery code.
Report the files changed, tests run, and any blockers.
'@ | axiowl send --to "Implementation Agent" --stdin

The tracking agent can be given a different message:

axiowl send --to "Drift Tracker" --body "Track the implementation against the original scope. Ask for receipts, source files used, and blockers. Do not perform the implementation."

That separation is the core workflow. AxiOwl is not analyzing the codebase and declaring drift on its own. It is giving the operator a reliable way to put different instructions into different provider sessions, keep sender identity visible, and require replies through a known channel.

Receipts are boundaries, not conclusions

The most important implementation detail is the receipt boundary.

The architecture docs distinguish accepted_by_axiowl from provider delivery proof. The CLI prints an AxiOwl handoff receipt when the request is accepted, includes the message ID, and points to the delivery log. The code also says that provider delivery, provider wake-up, and provider reply are not implied by that local receipt.

That is exactly what a drift tracker needs. If the implementer later says "done," the tracker can separate three questions:

1. Was the implementation request accepted by AxiOwl?
2. Did the provider edge report delivery or handoff evidence?
3. Did the implementing agent reply with useful evidence through AxiOwl?

Those are different states. Treating them as one event is how drift hides. A local handoff receipt proves that AxiOwl accepted and routed the request. It does not prove the other session understood the scope, preserved the source constraints, ran the right checks, or avoided unrelated edits.

The C++ tests enforce that distinction. The send pipeline test expects a successful send to return accepted_by_axiowl, not provider acceptance, and expects the log to record delivery_receipt as axiowl_only at the boundary before delivery worker/provider work. That makes the receipt useful without overselling it.

Replies are separate messages

AxiOwl also treats replies as their own messages. The simple architecture plan is explicit: never claim a recipient replied from a send receipt, because a reply is a new independent message.

That design fits drift tracking well. The implementing agent should reply with a summary, changed files, tests, and blockers. The tracking agent can then compare that reply against the original scope. If the implementation reply is vague, missing sources, or mentions files outside the assignment, the tracker has something concrete to challenge.

The current final visible body builder supports that loop. When sender identity resolves, AxiOwl builds a visible body that identifies the sender and appends an exact MCP reply call back to that sender. When runId and receiptForMessageId are present, the helper includes them for correlation. That lets a tracker ask, "Is this reply for the implementation request I sent, or a response to some other thread?"

The MCP server reinforces the same boundary. The axiowl_send_message tool description says success is an MCP-to-AxiOwl handoff receipt only. The server records inbound MCP send receipts with the target, body byte count, sender session ID, sender name, provider, host kind, identity source, runId, receiptForMessageId, source context, CLI exit code, and a receipt boundary marker. That is operator-grade evidence, not hidden inference.

Sender identity keeps the audit honest

Drift tracking breaks down when the tool cannot tell who is speaking. AxiOwl's docs and code put pressure on that point. For MCP sends, sender identity must come from provider/session metadata or a provider patch that supplies metadata programmatically. The developer docs say the MCP server should fail loudly when metadata is missing.

That means a tracking workflow can require replies from the actual implementing session, not from a guessed display name. The registry stores provider, provider session ID, node ID, source, sendability, last seen time, last verification time, and last error. Manual names and aliases are useful for humans, but provider-owned session IDs are what keep the routing grounded.

In practice, a tracker can ask for:

• the original message ID;
• the runId used for the workflow;
• the implementing session name;
• the provider/session identity from axiowl_whoami;
• the exact files changed;
• the verification run.

That is enough structure for a human operator to spot common drift patterns: the implementer edited outside the target path, used stale source material, claimed delivery from a local receipt, skipped the requested evidence, or answered from a different session than the one assigned.

Logs make the workflow inspectable

AxiOwl writes JSONL evidence rather than relying only on chat text. On Windows, the state root is under %LOCALAPPDATA%\AxiOwl. The implementation defines these paths:

• registry\agents.tsv for registered agents;
• registry\nodes.tsv for node records;
• logs\events.jsonl for evidence events;
• logs\delivery.jsonl for delivery stages;
• logs\create-lifecycle.jsonl for create/rename lifecycle events.

The message pipeline writes delivery stages such as request accepted, target resolved, route resolved, delivery worker handoff started, or delivery worker handoff failed. It also records rejected sends, targeted discovery attempts, sender repair attempts, and whether the receipt boundary was before provider delivery.

For drift tracking, those logs are not a replacement for judgment. They are the audit trail. A tracker can point to the message ID and say, "This request was accepted, but I do not yet have an independent reply with the expected receipt correlation," or "The sender identity was missing, so the reply path is not strong enough to treat as proof."

A practical two-agent loop

A solid drift-tracking loop is deliberately boring:

1. The operator sends a scoped implementation request to the implementer.
2. The operator sends the same scope, or a shorter checklist, to the tracking agent.
3. AxiOwl returns a handoff receipt and message ID.
4. The implementer replies through AxiOwl with changed files, tests, and blockers.
5. The tracker checks that reply against the original request and asks follow-up questions if the work moved.
6. The operator uses the logs, receipts, and final diff to decide whether the task is complete.

The value is not that AxiOwl decides what drift means. The value is that it makes the conversation inspectable enough for drift to be caught early. Separate sessions keep responsibilities clean. Explicit messages keep the scope visible. Receipts prevent false confidence. Logs preserve the event trail. Reply boundaries prevent a send from being mistaken for a completed result.

That is the real AxiOwl advantage for multi-agent work: it turns "agent coordination" into a series of addressable, auditable message handoffs that an operator can reason about.

Image prompt:

Create a polished graphic image related to: one AI agent tracking implementation drift while another agent works.

Subject: a technical control-room style scene with two separate computer terminals connected by precise glowing message lines, one terminal showing a structured checklist panel and the other showing a code editor panel, with a transparent receipt ledger sheet floating between them; no readable text.
Style: halfway between a clean symbolic icon and a realistic product/technical illustration; professional SaaS/technical marketing style; crisp edges; high detail; no text; no logos.
Background: solid #00ff00 chroma key green screen background covering the full canvas edge to edge.
Restrictions: no owl, no axolotl, no birds, no animals, no mascot, no text, no watermark.