We've open sourced TAP at Telara so agents can build reusable internal tools. A primitive puts useful execution behind defined inputs, outputs and required access. Engineers can review, change or author that code as they would other internal tooling.
Within a company, reuse raises some familiar engineering questions. Which version did we review? What assumptions does it make about the systems it calls? What happens if it gets only half the records? What may this particular caller do?
What a shared tool needs to return
Consider a customer-review primitive that resolves an account across CRM, support and billing, collects the records for a date range, and calculates agreed measures. These are steps you could package. The agent can then interpret the returned data and prepare the review.
For another team to reuse that procedure, its interface needs to preserve the details that made the result trustworthy:
- The account and date range supplied as inputs.
- The source records behind each calculation.
- Missing data, unmatched identifiers and failed calls.
- The systems and actions required to collect the data.
- The version of the procedure that produced the result.
An empty page, a denied request and an account with no support incidents mean different things. A useful tool should keep those distinctions in its output so the agent can decide what to do next. We want those expectations to become part of how a primitive is reviewed and maintained.
Reviewing a version and authorizing a call
A reviewed package still runs on behalf of a particular person or service. A colleague using the same code may be entitled to a different set of accounts. Required access belongs in the package declaration; the host and company policy determine whether the caller has it.
The review of a procedure for shared use and the approval of a change during execution are separate decisions. A company might approve a version for its teams while still requiring someone to approve a billing change requested by that version. The package's declared requirements do not grant new authority.
TAP uses the coding agent's existing tool connections. Claude Code and Codex have the best-supported connected-tool paths; other client paths have different limits in the compatibility table. The standalone runtime is MIT licensed and requires no Telara account, service or registry.
What we're building for TAP on Telara
Telara is the enterprise AI operating layer. AI clients connected through Telara can receive the company context they're entitled to use, with identity, scope and policy applied to the actions Telara mediates. Those actions can run autonomously, require approval or be blocked. The company retains the resulting work and decision record, including tool calls, approvals, outcomes and attribution.
We're extending that platform with verification, versioning, admin approval and distribution for TAP primitives. We want useful code created by one person's agent to become something colleagues' clients can reuse under company policy.
Models, tools and schemas will change. Reusable blocks give engineers and agents code they can inspect, test and update, along with a record of how it was used. A change to one part of a procedure should be something the team can review without rebuilding all of its tooling.
I work on TAP at Telara. If you support agents across shared company systems, I'd like to hear what you'd require before sharing an agent-written tool with another team, particularly how you'd review its version, authority and failure behavior.
TAP source and authoring guide.
This post was drafted with AI assistance.
Top comments (1)
Your distinction between missing data and no incidents matters at the calculation level too. Does TAP represent completeness for each calculated measure based on the source data it depends on, or only for the overall run?