Knowledge Base

The first principles behind the framework

18 questions, unpacked. What to look for, what good looks like, and where to go deeper.

C Control

Architecture that enforces what policy can't.

  1. Are agents restricted to what they can do, or only blocked from what they can't?

    You can't list everything an agent shouldn't do — the list is infinite. Start from zero authority, grant explicit permissions per task.

  2. When agents delegate to other agents, can authority only decrease?

    If your procurement agent approves purchases up to $5,000, any sub-agent should inherit that ceiling or lower. Does the architecture enforce this?

  3. What happens when an agent wanders into a use case you didn't anticipate?

    A general-purpose assistant told to handle your inbox might draft an email, then screen a job application. The risk tier depends on how open-ended the prompt is.

  4. Are your agents contained by architecture, or only by policy?

    Policy depends on compliance. Architecture enforces the boundary whether or not anyone cooperates. When things go wrong, only one of them holds.

  5. What happens when human oversight breaks down in practice?

    After the 20th approval prompt, people start clicking yes without reading. Decades of automation research confirm humans can't reliably monitor and then rapidly take control.

  6. How do you balance agent quality with data privacy?

    Agents get better with more context, but more context means more data exposure. Do your agents see only what they need, or everything because it's easier?

  7. Does your agent setup work when agents need to cross trust boundaries?

    Most approaches work within a single trust domain. When agents act across organisations, identity and authority need to travel with the request — verifiable at every step.

These questions become concrete when you map them to a real use case.

Open the Agent Profiler →