Core concepts
A few ideas explain how everything in TAS fits together.
Agents are code
An agent is a file in your repo under agents/, not a record in a vendor
console. Its model, instructions, connections, and tools are all declared in
that file. Because it’s a file, it has a history, a diff, an owner, and a review
trail — the same as any other code.
Every change is a pull request
You never edit a live agent in place. Changes — new agents, edits, and “improve the agent” feedback — are turned into a pull request against your repo. The authoring work (chat → diff) is performed by the Tembo Coding Agent Platform using the API key you set in workspace settings. You review and merge the PR like any other; the merged file is what runs.
Workspaces
A workspace maps to one GitHub repository and owns its members, connections, agents, automations, and runs. Switching workspaces switches all of that. Access is governed by roles.
Two agent frameworks
TAS runs two agent file formats, each as a passthrough into the upstream tool so you get its full power:
- Pydantic AgentSpec — the canonical authoring format. A YAML (or JSON) file
with
model,instructions, optionalconnections:, and TAS extensions likelabels:andtools_module:. Runs through a bundledpydantic-aiwrapper. - Cargo AI — a single-file JSON agent format, importable and run through the
bundled
cargo-aiCLI.
The Agents list and run pipeline detect the framework from the file’s shape.
Draft → stable versioning
An agent has a draft (the live file on your default branch) and, once you promote it, a stable snapshot frozen in the database. Runs default to the stable snapshot for predictability; the chat/iterate surface always runs the draft. Promotion records who promoted what and when, and you can compare versions — so “what changed and when did behavior shift?” is always answerable.
Connections and tools
Agents reach the outside world through Connections (authorized per user) and the tools those connections expose. TAS has two connection substrates — Composio and Native MCP — plus the option of sidecar Python tools for deterministic work. See Connections and Tools & Tool uses.
Acting user
Every run executes as a user, and that identity decides which connection credentials it uses. A manual run acts as you; a scheduled run acts as the automation’s owner; an event-triggered run acts as the trigger’s owner. This is why connections are authorized per person.