Introducing TAP: software building blocks for the agentic world

Telara Labs has open sourced TAP (Trusted Agent Primitives), a framework that lets AI agents package repeatable procedures as reusable, inspectable code with declared inputs, outputs and tool requirements. A runnable TAP package consists of a primitive.yaml manifest and a Bash, Python, JavaScript or TypeScript entrypoint, invoked by the agent through tap_run, with execution sandboxed via WebAssembly interpreters and tool, file and network requests checked against package declarations. The company says Claude Code and Codex currently offer the best-supported connected-tool experience, while other clients range from experimental to preview.

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 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. 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 https://github.com/Telara-Labs/TAP-Runtime where-it-runs shows. For a concrete look at the runtime interface, the repository's fan-out example https://github.com/Telara-Labs/TAP-Runtime/tree/v0.1.20/examples/fan-out 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. 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 https://github.com/Telara-Labs/TAP-Runtime install , authoring guide https://github.com/Telara-Labs/TAP-Runtime/blob/main/docs/writing-a-primitive.md and bundled examples https://github.com/Telara-Labs/TAP-Runtime/tree/main/examples . The runtime is MIT licensed and works without a Telara account, service or registry. At Telara https://telara.dev/ , 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.