Cookbook

Production-ready patterns for automating real work with contenox agents.

Each recipe is a pre-built solution: a chain or agent declaration that does the work and hands back structured output.

Most recipes here are written as chain files rather than agent declarations, because a recipe is a pipeline you point at — a fixed shape you can diff — rather than an agent you fire at an intent. Where a recipe needs branching, a per-step model, or a declared human gate, the chain is the only tier that says so.

The scripting recipes at the end are the other way round: one declaration under .contenox/agents/, fired by contenox run from a Makefile, a git hook or a CI step, with the report on stdout and an exit code to branch on.

Prerequisites

• Run contenox init in your project once, then either point Contenox at a local Ollama model or configure a cloud backend — see Quickstart.
• Tool access — local_shell, local_fs, and any MCP servers or registered remote tools — is governed by each chain’s tools_policies.

Several recipes below are one branch of a router rather than a standalone chain: a route task labels the request and hands it to the loop built for that label, with its own instruction, tool scope and budget. See Request routing for the shape.

Categories

• Stateful Agents with MCP — persistent memory across tool calls via MCP
• Browser Automation with Playwright MCP — drive a real browser with natural language
• Notion as a Tool — create, search, and update Notion via OAuth MCP
• The review specialist — “review the git diff” answered with a restatement, until a third branch in the router gave the request its own loop, with the write tools taken away
• The moderation gate — a cheap model classifies each message safe or unsafe before the expensive one runs
• Multi-provider fallback — a candidate list of models and providers with a retry policy, so a rate limit or outage falls through instead of failing
• Any API, a tool you authored — register an HTTP API as a tool with the credential hidden from the model and the endpoint surface narrowed
• Authoring your tool inventory — cut a large OpenAPI spec down to a hand-curated subset and register only that
• The pause is yours to define — write a HITL policy that pauses only on the tool calls you name, then activate it
• The nested permission bomb — give a workflow its own scoped credential and authored HITL policy instead of inheriting the operator’s access
• HubSpot via MCP — OAuth + pre-issued client credentials, works for any vendor MCP without dynamic registration
• The oracle — an adjudicating agent rules on a subagent’s routine asks so unattended runs finish; consequential ones still wait for you

Scripted work

A program is the caller: one declaration, fired by contenox run.

• Git & DevOps recipes — commit messages, branch reviews and test-failure triage as agents with read-only tool lists, wired to aliases and pipeline steps
• Codebase documentation — a docs agent that reads the tree, writes the architecture guide, and updates it from the diff that made it wrong
• Automated release notes — an agent reads the commit range with the git tools and writes RELEASE_NOTES.md; the exit code gates the release step
• Leads → HubSpot — one agent finds leads through Tavily’s MCP server, another writes them into HubSpot through a three-operation OpenAPI subset