Evelyn Wyatt

A shared action log would make the setup much easier to audit, especially when several specialists are involved. I’d take it one step further and attach the verification evidence to each action as well—not just which agent ran the command, but what observable state changed afterward. That would help distinguish “the command executed” from “the requested outcome actually happened.” It could also make disagreements between agents much easier to resolve because the system has a common evidence trail rather than relying on each agent’s interpretation of the result.

The schema-versus-value distinction is useful, but there’s an interesting gap between “valid output” and “correct output.” A response can satisfy the schema perfectly while extracting the wrong invoice total, misclassifying a document, or producing a summary that misses a critical fact. I’d treat those as separate testing layers: deterministic tests verify the contract and how the application handles the response, while a smaller set of evaluation cases checks semantic correctness against known expectations. That also makes flaky tests easier to avoid without weakening coverage. The goal isn't to make every assertion deterministic; it's to make each test responsible for a property that can actually be judged reliably.

The distinction between finding relevant evidence and preserving sufficient evidence for reasoning is an important one here. A retrieval system can return highly relevant chunks and still fail if the answer depends on a definition, exception, or relationship that wasn't included in the final evidence bundle. I’d be interested in evaluating “evidence completeness” alongside retrieval precision and recall: not just whether the expected passage was retrieved, but whether all dependencies required to justify the answer survived selection and packing. That metric could also make the RAG-versus-long-context decision more concrete. If a task repeatedly requires broad evidence relationships, long context or structured parent expansion may be the better baseline even when top-k retrieval looks strong.

The separation between core functionality and optional generation is the strongest part of this redesign. At IT Path Solutions, we’ve found that removing an LLM from the critical path is only half the reliability problem; the fallback still needs a clear product contract. If curated and generated content differ in difficulty, ambiguity, or expected behavior, the system can remain technically available while becoming inconsistent for users. Defining what the fallback must guarantee makes the architecture much stronger: the background model can improve the experience when it succeeds, but it should never change the guarantees of the core interaction. That turns AI into a true enrichment layer rather than a hidden dependency.

The invalidation layer may be just as important as the persistence layer here. At IT Path Solutions, we’ve found that persistent agent state becomes much safer when the system can distinguish between information that was never verified and information that was verified but is no longer valid. In a changing environment, allowing an old verified state to remain trusted can be more dangerous than having no memory at all. I like the idea of tracking instance changes because it gives the system a concrete trigger for revalidation. It could be even more useful if the invalidation reason became part of the state, whether the target changed, credentials expired, a process disappeared, or the original evidence became stale. That would give the agent a much clearer basis for deciding when it can safely resume and when it needs to verify again.

The task-topology point highlights a subtle failure mode: physical isolation can make logically dependent tasks look independent. Two agents may have completely separate worktrees and still be coupled through a shared API contract, schema, dependency version, or architectural assumption. That suggests dependency detection should happen before execution, not only when branches reach the merge queue. Even a lightweight contract map could help the dispatcher identify likely coupling and decide whether tasks should run concurrently or against an explicit predecessor. Isolation prevents accidental filesystem interference, but it doesn't remove semantic dependencies. The more agents run in parallel, the more important that distinction becomes.

The distinction also makes me think about how information should move between the two layers. Not everything an agent learns during a session deserves to become project memory. A temporary workaround, one-off debugging observation, and an architectural decision have very different lifetimes. A useful pattern could be to treat promotion into project memory as an explicit step: the agent identifies a finding, captures the evidence and scope, and only then proposes it as durable project knowledge. That would reduce the risk of turning every session observation into repository noise while still making important reasoning available to future sessions and teammates.

The decision-layer architecture also raises an interesting observability problem. If Jev sits between the agent and the tools, its value shouldn't be measured only by how much LLM cost it removes. You'd also want to know how often its decisions actually changed the downstream routing, how often the fallback path was triggered, and whether those decisions reduced unnecessary tool calls without increasing recovery work. That makes the decision layer measurable as an operational component rather than just a cheaper classifier. Over time, those signals could also reveal where the typed decision boundary is too narrow or where the agent is still sending cases that don't belong there.

The lifecycle of a stored decision seems like an important fourth question alongside where it lives, who reads it, and what it remembers. A rationale can be perfectly accurate when written and still become misleading after the architecture, dependencies, or business constraints change. At IT Path Solutions, we’ve found that durable context becomes much safer when the agent can distinguish between an active decision, a superseded one, and a decision that needs revalidation before reuse. That could make the “why” layer more than historical documentation—it becomes a piece of context with its own validity state. Otherwise, preserving the reasoning can solve one problem while quietly creating another: an agent confidently applying yesterday’s correct reasoning to today’s different system.

One point I’d emphasize is that the canonical product feed may become more important than the protocol choice itself. At IT Path Solutions, we’ve seen how having a reliable source of truth can simplify automation across different systems. If UCP and ACP are consuming the same product, pricing, inventory, and policy data, enterprises can treat the protocols as distribution layers rather than maintaining separate sources of truth. That also makes silent exclusion easier to diagnose, if an agent can’t surface a product, you can trace the issue back to the shared data layer instead of debugging two independent integrations.