Skip to main content
Telara
Blog

Open Source

Introducing TAP: software building blocks for the agentic world

Luis Alcaraz

We've open sourced TAP (Trusted Agent Primitives). We've been building it at Telara to let agents write reusable code for work they do repeatedly and run that code through the tools they already use.

Why we built it

Employees are asking AI agents to investigate issues, prepare customer reviews, check releases, and get work done across their company's CRM, ticketing, source control, and billing systems. In conversations we've had with executives, they've described seeing the same kinds of requests repeated across their organizations. Different people need the work done for different accounts or projects, but many of the steps are the same.

We want agents to build their own internal tools, much like engineers build software for people. Once an agent has worked out a procedure, it should be able to put the repeatable parts in code and use them again. A new account, project, or date range becomes an input to that code. The agent can spend its reasoning on the decisions the task needs.

That's what we mean by a primitive: a reusable block of code with defined inputs, outputs, and the tools and access it needs. We expect agents to write most of these primitives as they build their own tooling to get work done. Humans can write them too. A useful block should be something other people and their agents can reuse, and something they can build on for more complex work.

How TAP works

Consider checking whether a release is ready. A primitive could take a repository, a candidate commit, and a set of release requirements. It finds the changes since the previous release, follows references to the associated work items, retrieves CI results, and checks that the required reviews and tests are complete. The code handles pagination, matches results to the right commits and issues, and returns the checks that passed, anything missing, and links to the evidence.

The next release has different commits, issues, and test results. The procedure is still the same. The agent calls it with new inputs and uses the report to decide what needs attention.

Or consider preparing a customer account review. A primitive could take an account and a date range, resolve that customer's identifiers across the CRM, support, billing, and product systems, and collect the relevant records. It can follow pages of support tickets, group related incidents, normalize dates, calculate agreed usage and billing measures, and flag records that don't match. Each system's results feed the next steps in the code.

It returns the assembled account data, the calculations, and any gaps, with references to the source records. The agent can then reason about what those facts mean and prepare the review. When another team needs the same review for a different account, those collection and calculation steps can run again with new inputs.

These are examples of primitives you could write. A primitive can be a small part of a task, and we want those parts to be reusable when building longer procedures. It runs the code and reports the result, or the failure and what went wrong, so the agent can decide what to do next.

A primitive's design can also include a targeted reasoning step. That should be a specific decision with defined inputs and outputs. The parts where the process is already known stay in code.

A skill can provide instructions and scripts. TAP gives the executable code a defined interface and declares what it needs to run. The package uses the host's existing tool connections; it doesn't carry the credentials for those tools.

TAP Runtime runs that code in a WebAssembly sandbox. Calls to tools, commands, files, or the network go through the runner and are checked against the package's declarations. Changes need approval through supported client paths. From the command line, changes are refused by default unless you explicitly authorize them. The runner records requests and outcomes.

tap setup registers a local MCP server with the supported agents installed on your machine. The agent can find a primitive, read its inputs and requirements, and run it through tap_run in the session it's already working in. Claude Code and Codex provide the best-supported connected-tool experience today. Other clients range from experimental to preview; the compatibility table has the details.

Finding primitives in your own work

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

The CLI reads supported agent histories on your machine and looks for repeated chunks of execution. It sends no history off your machine. You can review a proposed primitive, accept or reject it, or prepare a handoff for your coding agent to refine it. Review and validate the code before relying on it.

The runtime is on GitHub under the MIT license. You can use it without a Telara account, service, or registry. The installation instructions, authoring guide, examples and Why TAP are there too.

What we're building for TAP on Telara

At Telara, we're working on security, sovereignty, and longevity for AI systems. TAP is part of that work. A primitive lays out what the code will do and what access it needs, and provides a package that can be used across compatible systems.

We want this work to last as tools, models, and systems change. That requires efficient, modular code people can inspect, test, and update. An agent should be able to keep using the useful code it's created, with changes to the parts that need them as the environment evolves.

Telara is the enterprise AI operating layer. It gives AI clients connected through the platform the company context they're entitled to use, and applies the organization's identity, scope, and policy to their actions. Those actions can run autonomously, require approval, or be blocked. Telara keeps a record of the work it mediates, including tool calls, approvals, outcomes, and who acted.

We're extending that platform with verification, versioning, admin approval, and distribution for TAP primitives. A procedure created by one person's agent should be able to become something colleagues' clients can use under company policy.

If your team is using AI across shared company systems, take a look at Telara. We're shaping the platform with enterprises and would like to hear what you need from it, including how you want to review and share primitives across your team.