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.
Top comments (6)
Reusable primitives for agents makes a lot of sense, and nice to see TAP open sourced. What's the first building block you'd suggest someone try if they're new to it?
I’d start with something you already ask your agent to do repeatedly. You can ask Claude Code to find or build a TAP primitive for it, or run
tap discoverto look for repeated patterns across your local agent sessions.Discover proposes candidates and drafts. Hand a useful one to Claude Code to refine, test and make resilient. You review what it does and the permissions it needs, then ask Claude to use it with new inputs next time.
The first building block should come from work that’s useful to you. Your agent handles building and running it.
Quick start
Thanks Luis, that's a helpful way to think about it. Starting from something I already ask my agent to do over and over makes sense, so I'll try tap discover on my own sessions first. Side note, as a Staff SDET I ran a quick automated QA pass on telara.dev while checking it out and it came back 89, so it's in good shape. Happy to pass along the short list if it's ever useful.
Thanks Wolf, I'd appreciate the short list. Please share the findings here, especially anything broken or confusing. And let me know how
tap discovergoes on your sessions.Sure, Luis. The two I'd fix first:
www.telara.devboth load on their own with no redirect. Your canonical tag helps, but picking one and permanently redirecting the other keeps search engines and shared links from splitting across two addresses.The rest are smaller, like a few form fields without labels and missing share-preview tags on a couple of inner pages. There's also one email security setting I'd rather not post in a public thread, so I can send that one privately if you want it.
Here's the page with your score and problem areas: qa-audit.com/teaser/edc21a2c-d101-... . The full report has every fix, plus a re-scan after you ship.
Thanks for sharing these, Wolf. Both main fixes are live now. telara.dev/llms.txt serves a plain-text file, and telara.dev permanently redirects to telara.dev while preserving the path and query. I also fixed the missing share-preview tags on the legal pages. If you have any more thoughts or findings on TAP, do keep us posted.