Tembo Agent Studio

Executive Summary

Tembo Agent Studio is a self-hosted control plane for shared AI agents. It keeps agent definitions in Git, exposes them through a web workspace, and connects execution to schedules, external events, human review, and an audit trail. The project is MIT-licensed; teams can maintain definitions themselves without using Tembo's commercial authoring service.^[1][2][3] It belongs in the team agent platforms comparison, especially for engineering-led teams that want to operate and version their own automations.

The useful distinction is between definition review, stable promotion, and approval of a real-world action. Agent Studio provides mechanisms for all three, but none implies that every change or tool call requires human approval. Tembo-assisted authoring defaults to a PR; admins can enable direct commits. Stable snapshots are promoted separately, and the Tasks Inbox supports explicit review workflows that agents must actually use.^[4][5][6]

Disclosure: Ry Walker is Tembo's co-founder and CEO. This profile covers both its open-source project and the optional relationship with its commercial platform.

---

Product Overview

An agent is a repository-backed specification with instructions, a model, and declared connections and tools. Pydantic definitions can include a sibling Python module, selected skills, delivery expectations, and an optional evaluation file. The studio adds an operating surface around those files: teammates run agents, inspect results and costs, configure automations, and propose improvements.^[10][11][7]

Definitions, authoring, and promotion

There are two authoring paths. Engineers can commit specifications directly. With a Tembo API key configured, a teammate can instead describe an agent or request an improvement from a run; Tembo's coding agent platform changes the connected repository. Each member can use a personal key, with a workspace key as fallback. Repository authorization in Tembo is also required for that integration.^[5][3]

Always PR is the default for assisted authoring. YOLO commits directly to the default branch when enabled by an administrator, and the setting change is audited. It does not bypass GitHub branch protection. Other operations, including manually committed definitions and configured guidance synchronization, are further reasons not to describe the system as universally PR-gated.^[4][3]

The live default-branch definition is draft. An owner or administrator can promote a numbered stable snapshot stored in the database. Before the first promotion, all runs use draft. After promotion, automated runs normally use stable, while a manual run defaults to a changed draft; a schedule can explicitly select draft. Teams therefore need a promotion policy as well as a Git review policy.^[5]

Optional evaluation sidecars make promotion more concrete. Assertions such as expected text, regular expressions, or output length must pass on the current draft before promotion. The LLM judge is informational: a judge failure does not fail the gate. Agents without an evaluation file remain ungated, and a GitHub-required check needs repository configuration beyond the studio's optional commit status.^[11]

Product surfaces and triggers

These entry points are distinct from tool connections. Connecting an agent to Gmail or Notion gives it tools; it does not automatically create a chat surface in that application.^[17]

A practical review workflow

A useful deployment pattern is an inbox assistant that reads incoming requests, drafts a response, and asks a teammate to approve delivery. This is a documented-component example, not a hands-on benchmark:

1. Define the agent's job and restrict its declared connection tools. Add a delivery contract identifying the expected inbox item or tool result, plus a small regression suite for the output that matters.^[10][11]
2. Test the draft against representative inputs, review its definition, and promote it. Select stable explicitly for the production schedule if that is the team's policy.^[5][13]
3. Have the agent call produce_inbox_item with context, an editable draft, and action options. The reviewer edits and approves the proposed action; the eventual action uses the reviewer's connections.^[6]
4. Inspect run status and delivery evidence, then turn useful corrections into a proposed agent improvement. Review and test that definition change before the next promotion.^[10][4]

The inbox deduplicates items using their source and external reference. Dismissing an item is terminal; deleting it permits a future item with that identity to appear again. These details matter for recurring triage. The inbox does not automatically intercept every other write-capable tool an agent has been granted.^[6][17]

---

Technical Architecture

The TypeScript/Next.js web application fronts a Rust API and Postgres database. Definitions live in a connected GitHub repository; run records, settings, connections, and stable snapshots have database state. Self-hosting therefore requires operating both the application and its persisted data, rather than backing up only the agent repository.^[1][5][3]

The documented Docker paths use source builds or prebuilt GHCR images; Railway, AWS, and Vercel guides cover additional deployments. The development bootstrap can create local email/password credentials when no OAuth provider is configured. Production teams can configure Google, Microsoft Entra ID, or generic OIDC instead. A reproducible deployment should pin a release and review migrations rather than silently inherit current-main capabilities.^[1][8]

Connections, custom tools, skills, and MCP

Studio exposes workspace model-key configuration for Anthropic and OpenAI. Tools come through native MCP connections, Composio, or custom sidecar code. For ordinary runs, the acting identity determines the connection: a manual caller, schedule owner, or trigger owner. Personal secrets take precedence over workspace fallback values; these are operational credentials, not automatically a model prompt.^[3][17]

A sibling Python module can export typed callable tools for tasks such as deterministic parsing or an internal API request. Its helper APIs can access authorized connections and secrets. Additional Python dependencies belong in the runtime image's requirements and require a rebuild; a specification is not an unrestricted package installer.^[18]

Skills live under skills/<name>/SKILL.md, with instructions, scripts, and resources, and agents opt into selected skills. Import paths include GitHub, ZIP uploads, skills.sh, and Anthropic's skill ecosystem. The documented Pydantic runtime can load skill resources and execute scripts locally. Sharing a skill format does not make imported code trusted or change its license.^[19]

MCP works in both directions: agents consume external tool servers, while external clients use Studio's own server to inspect and operate the workspace. The latter implements OAuth with PKCE and workspace-scoped authorization, with role checks in addition to granted scopes. This gives another authoring or control surface without making every connected client an administrator.^[15]

Execution, recovery, and observability

Run records expose status, model usage, estimated dollar cost, tool names, and success or failure. Delivery contracts can distinguish producing a reply from actually calling the declared delivery tool. Raw tool arguments and results are deliberately not persisted as delivery evidence because they can contain sensitive data.^[7][10]

The Pydantic path checkpoints after model and tool nodes. Following a restart, completed nodes need not replay, but a tool that was in flight when the process died can execute again. External writes still need provider-side idempotency or another deduplication design. Scheduled dispatch also has durable history and retry behavior; that does not make a failed third-party dependency disappear.^[7][13]

Dry Run is narrowly scoped. It stubs declared delivery tools; other tools can still perform writes. Unsupported paths, including Cargo AI and certain tool-router configurations, are rejected rather than silently pretending to be read-only. Treat it as a delivery rehearsal, not a universal no-side-effects mode.^[7]

Optional Memory on the development branch

The inspected main branch adds a managed connection to a separate Tembo Memory service. An instance admin configures its endpoint and controller token; Pydantic agents then receive ask, search, entity, card, and report tools. Cargo AI is unchanged. This integration is not present in v2026.9.2.^[17][9]

The server obtains short-lived agent credentials without passing the Memory administrator token to the subprocess. A dedicated Memory workspace is the default; an instance administrator can deliberately map multiple Studio workspaces to shared knowledge. That sharing decision changes the information boundary and should be reviewed explicitly.^[17]

Reports first enter an encrypted Postgres outbox and retry delivery across restarts. A queued receipt is not proof that extracted knowledge is already queryable. Reads report unavailability on an outage; dry runs may read but do not enqueue new reports. Routine prompts and outputs are not automatically copied into Memory. The behavior depends on deploying a compatible Memory service and the newer Studio code.^[17]

---

Security and Governance Boundaries

Repository write access, tool selection, secret scope, network access, and infrastructure administration remain consequential permissions. An MIT license and local deployment do not by themselves satisfy a data-residency policy. Teams should assess the entire configured path, including optional compression: ScaleDown sends selected context to an external compression service when enabled.^[18][10]

---

Strengths and Cautions

Strengths: definition files are inspectable and portable; stable snapshots separate deployment decisions from editing; optional assertion suites add a concrete regression gate; per-user connections and the review inbox support accountable team workflows. The MIT control plane can run independently of Tembo-assisted authoring.^{[5][11][6][3][2]}

Cautions: these controls require configuration and trusted runtime code. Feature parity varies by agent framework. Documentation and main can lead the published release. Estimated run costs are useful visibility, but the open request for administrator-controlled per-user spend caps should not be described as an available budget-enforcement feature.^[7][9][22]

What Developers Say

The September 16 search of public web, Hacker News, Reddit, and repository issues did not establish an independent first-hand deployment review. That limits conclusions about production reliability; it is not evidence that nobody uses the product.

There is useful operational evidence in the public issue tracker. On September 8, GitHub member kevine824-alt reported a deployment with many automations failing to access agents; the same-day resolution identified an expired GitHub token. This is a specific, affiliated report illustrating a repository-credential dependency, not a measured incident rate or unresolved system-wide outage.^[23]

On September 12, the same member filed the still-open request for per-user spend caps, explaining why editable agent-level limits did not satisfy that team's administrative requirement. It documents demand and a gap as of this review; it does not establish when or whether that proposal will ship.^[22]

---

Pricing & Licensing

As checked September 16, the separate Tembo platform lists Free with a $10 one-time usage allowance, Pro at $60/month with a $60 monthly allowance, and Max at $200/month with a $200 allowance. Allowances cover gateway model usage and VM compute; using external inference credentials can still leave compute charges. These are optional authoring-platform economics, not the price of running hand-written Studio agents.^[24]

No hosted Agent Studio service price was established in the repository and product sources reviewed. That is a research limit, not a claim that Tembo offers no deployment assistance. Imported skills, model providers, and integration services also retain their own terms.^[3][19][2]

---

Competitive Positioning

Studio is a strong candidate when a team has an infrastructure owner, wants inspectable definitions, and will actively manage model and tool permissions, tests, promotion, and credential lifecycle. It is a weaker fit when the priority is a managed service with minimal operations, a specific messaging adapter outside the verified surfaces, or execution of untrusted agent code without designing additional containment.

Viability Assessment

Published September releases and the inspected later commit establish active implementation, not a reliability guarantee. The public tracker provides evidence of real operational requirements, while independent deployment evidence remains limited in this review. Star counts and release volume are not useful substitutes for that missing evaluation.^{[8][9][23][22]}

A sensible pilot is one bounded, reviewable workflow: pin a version, exercise failures and recovery, check who can authorize an action, measure external costs, and test credential expiry before expanding the fleet. The project's most defensible value is the combination of inspectable definitions and team operating controls; its suitability depends on how those controls are configured and run.

---

Research by Ry Walker • methodology