Checkpoint: A Governed Agent Is More Than a Prompt
The first four chapters established Agentao’s session loop, its Python and ACP boundaries, and the different surfaces for capabilities, instructions, connectivity, interaction, observation, and intervention. This checkpoint connects those ideas through one request. The practical judgment is simple to state but demanding to apply: when Agentao proposes an action, a sound design should let you point to where the capability came from, where permission was decided, where execution was constrained, and where the result was recorded.
One request, several authority boundaries
Consider a tenant user who asks an in-product Agentao assistant to “find overdue work and create a follow-up task.” The request enters through the host application, which already knows the user and tenant. That identity should not be reconstructed by the model from free text. The host chooses or retrieves the Agentao session with the correct working directory, tools, policy, and transport.
The model may have a project-management Skill active. That Skill can tell it to inspect overdue work first, summarize the evidence, and ask before creating a task. The Skill improves the sequence and tone, but it does not give the model access to the project database. The actual lookup is a Tool whose implementation holds the tenant context and calls the business API. If the host instead uses an MCP server for the project system, that external server becomes the capability provider and adds its own credential and process boundary. The model still sees a callable operation, but the host must now review how the server is scoped and trusted.
The first lookup may be read-only and pass through an appropriate policy without interrupting the user. The returned records become evidence for the next model step. When the model proposes creating a task, the meaning changes: a write is about to cross into an external system. PermissionEngine can allow, deny, or ask based on the tool and arguments. If the result is ASK, Transport carries the approval request to the user interface or to an explicit unattended policy. A positive click is not the same as business authorization; the Tool or API must still check that this user may create the task in this tenant.
If the call proceeds, the execution boundary matters. A local business Tool may be limited by its backend’s authorization and network route. An MCP operation may run in a child process or remote service with different credentials. A shell or web tool may also be subject to filesystem, network, or sandbox controls. Agentao’s runtime policy decides whether a call should proceed, but the operating system, container, VPC, or API can constrain what the call can actually reach.
Finally, the host needs two kinds of evidence. The user interface may receive streamed text and tool progress through Transport. The audit system may record stable tool and permission lifecycle facts through the host contract. Those records answer different questions: the UI asks “what should I display now?” while the audit asks “what action was requested, which policy applied, and what happened?” Treating the two streams as interchangeable would either make the UI too rigid or make compliance depend on internal event details.