DEV Community: Luis Alcaraz

Introducing TAP: software building blocks for the agentic world

Luis Alcaraz — Wed, 07 Oct 2026 03:05:38 +0000

We've open sourced TAP (Trusted Agent Primitives) at Telara so agents can build reusable internal tools for the work they do repeatedly. The packages are code that developers can write, inspect and maintain too.

Employees ask agents to investigate issues, prepare customer reviews and check releases across CRM, ticketing, source control and billing systems. Executives we've spoken with describe those requests recurring across their organizations. A different account or project often means different inputs to the same procedure.

Once an agent has worked out a procedure, it should be able to put the repeatable parts in code and use them again. The agent can spend its reasoning on the decisions the task needs.

A procedure you could package

A release-readiness primitive could take a repository, a candidate commit and release requirements. It collects changes since the last release, follows references to work items, retrieves CI results and checks required reviews. Its code handles pagination and matches records to the right commits and issues.

The output is the checks that passed, anything missing, and links to the evidence. The next release supplies new inputs. The agent uses the report to decide what needs attention.

This is an example of a primitive you could write. Its interface would need to make the inputs and the returned evidence clear:

Input	What the procedure returns
Repository and candidate commit	Changes and work items associated with that candidate
Required checks and reviews	Passed checks, missing checks and evidence links
Previous release	The range used to collect changes

The same release requirements can apply to the next candidate. A smaller block that resolves changes to work items could also be useful in an incident investigation. That's the engineering idea behind primitives: build something useful once, give it a clear interface, and make it available to other people and their agents.

The execution interface

A runnable TAP package has a primitive.yaml and a source entrypoint: Bash, Python, JavaScript or TypeScript. The manifest declares what the program needs. The agent loads the primitive's interface and invokes it through tap_run; the code returns its result or a failure the agent can act on.

Packages use the host's existing tool connections. They don't contain the credentials for those tools, and declaring a requirement doesn't grant permission.

TAP Runtime runs supported entrypoints through WebAssembly interpreters. Tool, command, file and network requests go through the runner and are checked against package declarations. Changes need approval through supported client paths; command-line changes are refused by default unless explicitly authorized.

Claude Code and Codex provide the best-supported connected-tool experience today. Registration and execution are different capabilities; other clients range from experimental to preview, as the compatibility table shows.

For a concrete look at the runtime interface, the repository's fan-out example uses a connected mail-search tool, sends four searches together with tap.call_many, and reports first-page counts for each time window. Its manifest declares the tools it may call and marks them read-only. It's deliberately small; the larger release-review procedure above is something you could build from reusable parts.

The code can keep intermediate records between calls, use one response to choose the next request, and handle ordinary branches. The agent receives the assembled result. A primitive's design can also include a specific reasoning decision with defined inputs and outputs; the repeatable execution around it stays in code.

Try it on your own work

npm install -g @telaralabs/tap
tap setup
tap discover

tap discover reads supported agent histories on your machine and proposes primitives from repeated work. It sends no history off the machine. Review the code, its assumptions and failure cases before using a proposal.

Start with the installation guide, authoring guide and bundled examples. The runtime is MIT licensed and works without a Telara account, service or registry.

At Telara, we're also working on how these tools become useful across a company. Telara is the enterprise AI operating layer: it connects AI clients to entitled company context and applies identity, scope and policy to the work it mediates. We're extending it with verification, versioning, admin approval and distribution for primitives. A colleague's agent should be able to reuse useful code under that colleague's company permissions.

I'd like feedback on which procedures you'd package, what the inputs and outputs should be, and what makes a tool worth sharing with another person's agent.

I work on TAP at Telara. This post was drafted with AI assistance.

What we're building for TAP on Telara

Luis Alcaraz — Tue, 06 Oct 2026 22:32:29 +0000

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.