Aegis — Post-Execution Truth Layer for AI Agents

• 

  reconciliation_report.png

• 

  approval_gate.png

• 

  corrected_status.png

Inspiration

Aegis was inspired by a simple but important gap in agent workflows: an agent can claim a task is done even when the final state does not actually match the goal. In fast-moving agent systems, that creates a trust problem for developers, reviewers, and users.

Aegis was built to close that gap by acting as a post-execution truth layer for AI agents. Instead of replacing planning or orchestration, it verifies what really happened after execution, checks the resulting state, and highlights missed capabilities or silent failures.

What it does

Aegis runs after a worker agent finishes and compares the approved task contract against trace evidence and final system state.

It can:

• verify whether success criteria were actually satisfied,
• detect drift between what was claimed and what was true,
• audit whether a better available capability was missed,
• generate a minimal corrective sub-plan,
• and request approval before any repair pass runs.

In short, Aegis answers the question: when the agent says it is done, is that actually true?

How we built it

Aegis is built in Python as an adapter-based reconciliation system.

The core design includes:

• a task contract builder,
• a capability registry,
• execution adapters,
• trace normalization,
• state verification,
• capability auditing,
• a reconciliation engine,
• a repair planner,
• an approval gate,
• and a final verifier.

The implementation supports both a simulated offline demo and a live agent path with Google ADK and tracing. The architecture was designed so the core reconciliation logic stays runtime-agnostic while integrations remain adapter-specific.

Challenges we ran into

The hardest part was not building an agent that runs, but building a system that can prove whether the agent truly succeeded.

Another challenge was keeping Aegis narrow enough to be useful. It needed to avoid becoming a generic agent platform and instead focus on the unique post-execution layer: evidence, verification, drift detection, and repair.

Designing a reliable repair loop was also challenging because fixes should be minimal, approved, and targeted only at the unmet criteria rather than rerunning everything.

What we learned

We learned that agent output is not the same as task completion.

We also learned that:

• trace data becomes much more useful when it is normalized into structured evidence,
• verification is stronger when it checks real state, not just text,
• and a small, focused architecture is often more compelling than a broad one.

Most importantly, we learned that trust in agent systems needs an audit layer, not just an execution layer.

Built With

• adk
• arize
• google
• openinference
• opentelemetry
• phoenix
• pydantic
• python
• rich