Grounding

An agent needs reliable information to decide what to do, and enforced limits on what it is allowed to do. These are related, but different: an agent can stay within its permissions and still misunderstand a request or give an incorrect explanation.

In Teaflask, grounding means giving the agent product-specific information to base its decisions on. Execution controls determine which information and operations it can access, and under what conditions.

Giving the agent a basis for its decisions

Documentation explains the meaning behind your product: what features do, which rules apply, and how workflows fit together. Live information from the app or API can establish the current situation. An action definition describes an operation and the inputs it accepts.

These sources work together: documentation explains the rules, live information establishes the current state, and action definitions describe the available operations. Knowing that an operation exists does not, by itself, establish whether it is appropriate for the user's request.

The agent's knowledge scope limits which released docs its documentation tools can access. This scope is applied by Teaflask, not selected by the model as part of a search. Other information, such as page content or API results, becomes available through the corresponding tools you grant.

Keeping product knowledge current

Teaflask automatically verifies checkable claims in your released documentation against your connected codebase. As changes land on the branch you designate as production, it re-runs the affected docs' checks to identify claims that no longer match the code.

When Teaflask identifies outdated documentation, it proposes a corrected revision for you to review. It does not silently replace the released content: you decide when to release the update. This helps keep the agent's product knowledge aligned with the product your users are running.

Not all guidance can be verified against code. Business policies or explanations without checkable code references still need human review. See Verification for how Teaflask checks claims, reports findings, and proposes updates.

Enforcing what the agent may do

Instructions describe how you want the agent to behave. They are not a substitute for access controls. Asking an agent not to perform a sensitive operation is different from withholding the tool that would perform it.

For catalog API actions, several controls work together:

• Agent grants select which registered operations an agent can use. Adding an operation to the organization's catalog does not grant it to every agent.
• Action policies determine whether execution is allowed without approval, requires the user's approval, or is denied.
• Request validation checks the supplied arguments against the action's schema. The request's method and path template come from the catalog, while the destination comes from your adapter. The model supplies parameter values, not an arbitrary API request.
• API authorization determines whether the current user is permitted to perform the operation on the requested resource. This remains your application's responsibility.

These controls answer different questions. A valid input does not prove that the user owns the target record. User approval does not override your API's permissions. A permitted operation does not prove it is the right operation for the user's intent.

Other capabilities have their own boundaries. Knowledge scope limits documentation access, while navigation can be restricted to configured path prefixes. Catalog action policies do not replace the need to review those capabilities separately. See Actions and Agent knowledge for their configuration.

These controls restrict what the agent can access and execute; they do not guarantee that every response or decision is correct.

Continue reading

• Production checklist: checking the integration and its behavior before rollout.
• Conversations: reviewing messages, tool calls, and action results.
• Trust: security, data handling, and isolation in more detail.