Developer
Add a capability we have never heard of.
Your warehouse system, your pricing engine, your internal service. Describe it once and it becomes a registry entry behaving exactly like a built-in capability: permissioned, approvable, rate-limited, audited and revocable.
What connects
Any HTTP service, described by hand or imported from an OpenAPI document.
What crosses the boundary
- Into the agent: the outputs your tool declares.
- Out of the agent: the inputs your tool declares, validated against its schema.
- Never: your service's credentials. They are held in the vault and injected at call time.
The capabilities this exposes
- The capabilities you define
Setting it up
- 1Describe the tool: name, inputs, output, authentication, risk level.
- 2Store its credential as a secret, scoped by agent and environment.
- 3Test it in the sandbox against a mock.
- 4Grant it to specific agents, and review before production.
Permissions
Whatever your service requires, held as a secret and never placed in an agent's context. The risk level you declare is checked against what the tool actually does, and a tool declared low risk that writes to a ledger will be caught in review.
Jobs an agent can own once this is connected
- Check stock before promising a delivery date
- Look up a price from your own pricing rules
- Read a status from a system with no public API
Where it stops
A tool you wrote gets the same governance as a built-in one; there is no weaker path for custom code. You choose how narrow it is, and one endpoint exposed as six narrow tools is almost always better than one wide one — each can be granted to a different agent and refused to the others. The platform cannot make a badly scoped tool safe.
Developer
Others in this category.
Give AI a job.
Build an agent, choose what it can access, define what it may do, and deploy it to work safely across your business.
No code required · Full SDKs and API · Stop any agent instantly · [email protected]