Tools & policy
Tools are explicit capabilities with schemas and execution behavior. Policy determines which of those capabilities are visible and allowed in a given runtime context.
Tool contract
A tool describes identity, input/output schemas, metadata, side-effect classification, and error behavior. Registries add namespaces, enable/disable controls, typed validation, contextual handlers, deadlines, lifecycle hooks, and dependency-injected runtime context.
Visibility before execution
Large tool catalogs should not be pushed into every model request. Agent RT supports static policy, runtime visibility filters, deferred schemas, capability search, and Decision-model selection so the active tool set can be narrowed before the model sees it.
Validate twice conceptually
Capability visibility controls what the model can discover; dispatch checks what the runtime will actually execute. Keeping those boundaries separate helps prevent stale or malformed model calls from bypassing the current policy.
Guardrails and approvals
Agent RT has four distinct guardrail boundaries: user/model-boundary input, model output, tool input, and tool output. The built-in conversation boundary layer is enabled by default and checks message size, content-part count, control characters, and assistant output role. Model-backed tool-input screening is separate and opt-in; when enabled, its default model is agent-action-guard (Agent Action Guard), and it runs before argument validation and before tool side effects.
Human-in-the-loop flows can pause execution for missing information, review, edits, or approval rather than encoding consequential authorization inside model text. See Features & defaults for execution order, exact defaults, configuration examples, prompt-injection defenses, exfiltration policy, permissions, and production guidance.