When to use Tag
Use Tag for one-off delegated work:- investigate a benchmark failure
- summarize a repository or run result
- produce a short research note with a definition of done
- give an MCP-enabled agent a smaller task surface than the full Factory API
Install and authenticate
Install the Research SDK package selected in the release checklist:Create a session
sessions.create creates a Tag session, starts its bound Managed Research run,
and returns both session_id and run_id.
scope_id, the backend creates or reuses the default Tag scope for
the organization.
Steer the active run
Usesessions.messages.send to add guidance to the same Tag session. A successful steer
keeps the same run_id; it does not start another run.
Poll for the receipt
sessions.get returns coarse status: queued, running, done, or failed.
When the session is terminal, the receipt includes the run id, terminal state,
run URL, and either artifact URLs or an explicit empty-artifact reason.
Smoke script
Thesynth-ai package includes examples/tag_delegate_smoke.py for delegate,
steer, and receipt checks:
synth-dev wrapper loads SYNTH_API_KEY from the local synth-ai/.env and
maps slot ports:
MCP tools
Tag tools intentionally usetag_* names so delegate sessions do not collide
with the lower-level smr_* Factory and run-control tools.
Tag vs Factory
Tag can later link into Factory programs, but v1 treats Factory linking,
Gardener, Seraph, routines, and memory as future work.
Limits and errors
Tag uses existing organization-level Managed Research limits. Launch denials surface through the same error classes as normal runs:
See Preflight and Errors for the
broader Managed Research launch-denial vocabulary.
Beta scope
Synth Tag v1 ships:- SDK and MCP delegate/steer/receipt
- default Tag scope per organization
- optional definition of done stored on the session and passed into the run
- run receipts with artifact pointers or explicit empty-artifact reasons