Authoring agents

Agents are authored as files and changed through pull requests. You can write those files directly, but the usual path is to describe what you want and let TAS open the PR for you.

Creating an agent from chat

Describe the agent you want — its job, its tone, the services it should use. TAS hands the request to the Tembo Coding Agent Platform, which writes the agent file and opens a pull request against your repo. Review and merge it; the agent then shows up in the Agents list. (This requires a Tembo API key in Settings.)

Not sure what to ask for? Example Agents has ready-to-use, copy-paste prompts (email triage, ticket roundups, …) that adapt to whatever you’ve connected.

The agent file (Pydantic AgentSpec)

A minimal agent is a YAML file under agents/pydantic-agentspec/:

name: standup-summary
model: anthropic:claude-sonnet-5
description: Summarize yesterday's commits into a standup note.
instructions: |
  When invoked, summarize the team's activity in three bullet points.
  Be concise and factual.

Key fields:

name (required) — the slug identifier; must match the filename (name: foo → foo.yaml); lowercase letters, digits, hyphens. It’s the stable key for URLs, runs, and automations, so don’t change it after creation.
title (optional) — a free-text display name shown in the UI (e.g. title: "Inbox Triage"). When you create an agent you can type any name; the filename slug is derived from it and the text is saved as title. The UI falls back to name when there’s no title.
model (required) — provider:model, e.g. anthropic:claude-sonnet-5, anthropic:claude-opus-4-8, anthropic:claude-fable-5, openai:gpt-5.5, openai:gpt-4o-mini. The provider’s key must be set in Settings → LLM Providers.
instructions (required) — the system prompt, usually a | block scalar.
connections: (optional) — external services the agent calls; see Connections.
tools_module: (optional) — a sibling Python file of deterministic tool functions; see Sidecar Python tools.
labels: (optional) — tags used for grouping and for scoping which Slack app may launch the agent.
scaledown: (optional) — opt into ScaleDown prompt compression to cut frontier-model tokens (off / prompt / aggressive).
skills: (optional) — names of Skills to load, giving the agent reusable instructions/procedures on top of instructions.
model_settings: (optional) — a map of model knobs passed through to the model, e.g. max_tokens, temperature, parallel_tool_calls. TAS defaults parallel_tool_calls: false (so tools run one at a time unless you set it true) and, for Anthropic models, enables prompt caching — both overridable here.
```
model_settings:
  max_tokens: 6144
  temperature: 0.2
```
request_limit: (optional) — cap the number of model requests in a single run (Pydantic AI UsageLimits). Defaults to 50; lower it to bound cost/looping on a tool-heavy agent.
retries: (optional, int) — how many times a failing tool call may be retried within a run.
instrument: (optional, bool) — toggle Pydantic AI run instrumentation (OpenTelemetry spans) for this agent.

Your connected repo also carries an authoring guide (AGENTS.md and per-framework AGENT_GUIDE.md) that TAS keeps current — that’s the canonical, always-up-to-date field reference for coding agents.

Choosing a model

Model choice is a cost/reliability tradeoff:

Default to anthropic:claude-sonnet-5 for most agents, tools or not. It’s the most agentic Sonnet yet — decisive about when to act, so it doesn’t hedge (“would you like me to…”) the way earlier Sonnet and mini tiers do — with reasoning and tool use close to Opus 4.8 at lower cost.
Need more than Sonnet 5? Step up to anthropic:claude-opus-4-8, and to anthropic:claude-fable-5 (Anthropic’s most capable, Mythos-class) for the hardest reasoning and long-horizon agentic work — reach for Fable only when Opus 4.8 isn’t enough.
Cheaper, simpler jobs. anthropic:claude-haiku-4-5 and the mini tiers are fine for no-tools or high-volume work with a single, well-defined job and imperative instructions; they tend to hedge on tool calls, so prefer Sonnet 5 for anything that declares connections:. Compare cost side-by-side on the Runs page.

ScaleDown prompt compression

ScaleDown is an optional prompt-compression layer: bulky context is routed through a small model that rewrites it to far fewer tokens while preserving the query, so you spend fewer tokens on the expensive frontier model. It’s opt-in per agent and a no-op unless a workspace ScaleDown API key is set under Settings → LLM Providers.

Enable it with the scaledown: field:

name: long-research
model: anthropic:claude-opus-4-8
scaledown: prompt          # off (default) | prompt | aggressive
instructions: |
  …

Modes:

off (default, or field absent) — no compression; runs are byte-identical to having no key.
prompt — compress the static instructions once at startup. The safe, recommended default: it’s lossy only on your own system prompt, adds no per-turn latency, and is cache-friendly — the compressed instructions are identical every turn, so Anthropic prompt caching still hits (on a smaller prefix).
aggressive — also compress bulky history blocks (large tool outputs, user context) on each turn. Best for long, tool-heavy, cost-sensitive runs. Each block is compressed once and frozen (memoized by content), so repeated turns send identical bytes and prompt caching keeps working instead of thrashing. Message structure (tool calls / tool results) and the most recent turn are left untouched.

Object form tunes it:

scaledown:
  mode: aggressive
  rate: auto             # ScaleDown compression rate
  min_tokens: 400        # only compress blocks larger than this

Notes

Lossy by design. Compression drops detail to save tokens. Start with prompt; move to aggressive only where token cost matters and you’ve confirmed quality holds.
Best-effort. If ScaleDown is unreachable or errors, the original text is used — a run never fails because of compression.
Where to see it. Token savings are logged in the instance/container logs ([scaledown] N → M tokens); they are not yet surfaced in the run-detail UI.

Iterating

Chat-to-edit — probe the live draft in the agent chat surface, then submit a change request that opens a PR. See Agent lifecycle.
Improve the Agent from any run turns feedback into a PR — see Improvements.
Promote a draft to a stable version when you’re happy with it; automated runs serve stable by default. See Agent lifecycle → promoting.

Your agent list, stars, and forking

All members’ agents live in one repo, so the agents list can get crowded. To keep your day-to-day view tidy:

Star any agent (the ☆ on its row) to add it to your personal list. The list defaults to Mine + Starred — agents you own or starred — with a View all toggle to see everyone’s. Stars are personal; they don’t change the shared repo or the labels: taxonomy.
Fork an agent (the Fork button on its page) to make your own editable copy. The copy is named with an owner prefix — sales-gen forked by ryw becomes ryw.sales-gen — so two people can each keep their own without a name collision, and the fork is owned by you (so it shows in your default list). A forked tool-using agent shares the original’s tools_module: file (same folder) until you change it. Forking copies the spec verbatim; edits go through the usual PR flow.

The optional <handle>. prefix is the only place a dot is allowed in an agent name — plain names stay kebab-case (a-z0-9 and hyphens).