The short answer
Begin an AgentPlat integration with the smallest tool catalog that supports one concrete task. Define each tool’s scope and effect, then add identity, policy and retry controls at the path that invokes it. Tool availability alone does not authorize every use.
Describe the job before exposing connectors
The integration guide recommends a narrow capability catalog rather than exposing every tool to every agent. Start by writing the one result your application needs.
An illustrative research assistant may initially need to read approved reference material and submit a draft. It does not necessarily need permission to update the original source, contact customers or modify membership. Keeping those operations outside the first slice makes both implementation and evaluation more specific.
Give each tool an operational description
For a proposed tool, record its accepted input, permitted resource scope, returned evidence and whether it changes another system. This is a recommended integration inventory, not an additional AgentPlat schema.
| Concern | Integration question |
|---|---|
| Scope | Which tenant, Room and resource may it address? |
| Effect | Does it read, create or modify something? |
| Retry | How is an uncertain outcome reconciled? |
| Evidence | What record explains its result? |
Enforce consequential operations at execution
The protected-action reference calls for checks on current authority, assignment, policy, expiry, idempotency and approvals. A model's selection of a tool is not a replacement for those checks.
If the first read-only workflow later needs a write, review that expansion explicitly. Add the corresponding checkpoint and sink behavior rather than assuming the connector's existing credentials make the write acceptable.
Preserve scoped knowledge and output references
The Room tool bridges support revision-authorized knowledge reads, scoped memory and artifacts with provenance. Use those references to connect an output to the information the tool supplied.
Do not implement a broad “read any file” escape hatch beside a carefully scoped knowledge bridge. The narrower interface only helps when relevant calls actually pass through it. Record any direct provider or connector path that remains outside the intended controls.
Expand after observing the bounded workflow
Test the intended call, an out-of-scope resource, a denied effect and a retry with an unresolved outcome. Inspect the retained result rather than only the model's final explanation.
Use the findings to decide whether another capability is necessary. Each new tool should have an owner for credentials, failure handling and evidence. A larger catalog is valuable only when the application can still explain and constrain the work it enables.
Sources and further reading
Documentation reviewed . Consult the linked documentation for current implementation details.