Bots and examples
Bots that run on your computers use a local Git repo for their Instructions, Tools, and memory. Start from a bundled template; GitHub is optional. Cloud external agents do not need a local repo.
Two kinds of bots
Bots on your team chart are teammates, like the humans on your team: each runs part of the work. Message bots clear each human’s inbox.
| Teammates | Message bots | |
|---|---|---|
| What | A role on the team chart that owns a job | One per human, for their email |
| Examples | BotOps, support, sales, content, market analyst, or any role you describe to BotOps | One for each human who wants one |
| What it does | Takes tasks, runs routines, posts daily and weekly updates, and asks for help | Sorts email with decisions, applies your mail rules, drafts replies, and flags what truly needs you |
| Sends email? | Drafts until sending is turned on for the bot | Drafts until sending is turned on for the bot |
Message bots start with one morning mail brief: weekdays at 07:30 in America/Los_Angeles. Change the Routine’s time zone in Settings → Routines to match your team. The routine is initially disabled; setup turns it on. Each reads only its assigned mailbox by default; reading reports’ mail is off. Ask BotOps for extra passes or access to the mail of humans who report to that human. To add one, choose Inbox Manager in Setup or Settings → Bots → Add from template, or ask BotOps, and name the mailbox. On Google Workspace, one service account can cover the mailboxes you grant.
Calendar access is separate from Gmail grants. Tico’s MCP/API calendar tools let a message bot read and schedule on the team owner’s calendar by default, or its operator’s calendar; other team calendars are refused on this path. The mail-local calendar commands can read or create events for any address in the team roster, regardless of Gmail grants or read_only; addresses outside the roster need an explicit google-calendar Tool entry with the required verbs. The computer also needs the Google service-account setup. See the two calendar paths.
BotOps
Every install starts with BotOps. It sets up, repairs, and manages your other bots, and builds new ones. When you ask in chat, BotOps finishes setup, takes the bot live and tests it; an unattended setup task reports readiness to its owner. Missing Credentials use cards in chat. Tico creates it from a bundled local template, so you can set up bots and get work done without a GitHub account. Connect GitHub later if you want private repos in your own organization, and enable Allow Tico to create bot repositories. See GitHub setup.
Bot templates
Browse every template and its changelog to see each role, its source instructions and its history.
Tico includes templates named for jobs a team would hire, grouped by department. The template directory lists the catalog and additional built-in or helper templates at its recorded source revision. Add them in the setup wizard, or ask BotOps later. Each starts with a draft-only first routine. A bot drafts messages to outsiders until sending is turned on for it.
| Group | Examples |
|---|---|
| Sales | Sales Manager, Sales Development Representative, Account Executive, Account Manager |
| Marketing | Head of Marketing, Content Marketer, SEO Specialist |
| Customer Support | Head of Customer Support, Customer Success Manager |
| Finance | Head of Finance, Bookkeeper, FP&A Analyst |
| Legal and HR | General Counsel, Paralegal, Head of People, Recruiter |
| Product and Engineering | Head of Product, Product Manager, Head of Engineering, Site Reliability Engineer |
The full list is in docs/starter-bots.md.
Example bots
| Bot | What it does |
|---|---|
| example-support | Triages support, drafts replies, and routes what needs a human. |
| example-sales | Researches accounts, drafts outreach, and keeps the pipeline current. |
| example-inbox | Triages one human’s inbox with rules for each mailbox. |
| example-content | Plans and drafts posts and articles for a human to publish. |
Code review with different approaches
Give reviewers independent ways to examine a change. A heterogeneous review team varies its prompts, context selection and tools, as well as its models. This can expose different blind spots; it is a design choice to evaluate on your own changes, not a guarantee that more reviewers find every bug.
| Role | Suggested approach |
|---|---|
| First reviewer | Review a compact patch packet: the complete changed-file list, relevant requirements, numbered hunks and context around enclosing functions. Return structured findings with a concrete trigger, impact and source location. |
| Second reviewer | Read the updated complete change independently. Trace affected callers, permission boundaries, data flows, error paths and tests in the repository. Look for interactions the patch-focused review may miss. |
| Engineering lead | Coordinate the work and resolve workflow blockers. Check that the required reviews and test receipts refer to the intended revision; delegate technical review to the reviewers. |
The first approach can borrow from PR-Agent: token-aware patch packing, dynamic surrounding context, structured findings and explicit coverage reporting. Keep deleted code and omitted files visible. A removed permission check or test can be the most important part of a change.
Reviewer settings and starting choices
Configure each reviewer in Settings → Bots and give it a distinct review playbook through More → Edit Instructions. The two-reviewer pattern above is a recommended setup, rather than a pair installed automatically for every team.
| Setting | Current behavior or recommended choice |
|---|---|
| Review model | A bot uses its own configured model by default. A company check-model override is a separate choice. For an independent review, verify the model that actually ran, including any fallback. |
| Reasoning effort | The Senior Software Engineer template recommends high effort. Keep enough reasoning for technical review; try a lower effort only after checking important-bug detection and rework on representative changes. |
| Compact at | 250k tokens is the default for Claude Code and Codex. It is a context-compaction trigger, not a limit on all tokens a review can consume across many calls. |
| Scope and context | Use the task’s own session. Start with a complete change manifest and retrieve relevant source and tests as needed. Keep historical learnings searchable instead of loading every old note. |
| Review cadence | Review once at the assigned step. Use a second independent review for larger or risky changes. An explicitly requested follow-up can use the prior findings and affected delta; an ordinary edit need not start another full review. |
| Evidence | Record the reviewed base and head, findings, coverage, relevant checks and limitations. A changed revision makes the corresponding review evidence stale. Reuse checks only when their relevant inputs still match. |
| Unit tests | Builder and QA own test execution. Reviewers inspect revision-matched results and relevant coverage without rerunning unit tests. If evidence is missing or stale, request the focused check from its owner and record the gap. |
Reviewers need real code, not just summaries. Expand into callers and contracts when the diff cannot answer a material question. If part of a change was not examined, name that gap. Keep failed checks visible and distinguish a complete review from a partial one.
External PR reviewers
PR-Agent is an open-source external pull-request reviewer that can run through a GitHub Action, its CLI or a self-hosted service. It is a separate project from Qodo’s hosted offering. It can work alongside Tico’s bots on the same repository; link the PR and review result to the Tico task and define which reviewer owns each review step.
This is a Git-provider workflow, not a built-in Tico runner harness or a direct MCP connection. Set up PR-Agent using its installation guide, then use its actual revision-specific findings as review evidence. Connecting a general-purpose external agent to Tico uses the separate MCP connection guide. Tico does not automatically translate an external bot’s comment into a required review approval.
Make your own
- Open Settings → Bots → Add from template, or ask BotOps to build a bot.
- Choose a template and say what it should do.
- BotOps builds the repo and adds the bot to your team chart.
“Respond to customer support questions as they come in. Use our documentation, and escalate to me when you’re unsure. As you go, build software to catalog good responses, keep macros, and add any other tools that make you the best support bot possible. Your goal: accurate, friendly responses that follow our documented team guidelines, sent within 5 minutes.”
Set up by harness
| Harness | Where it runs |
|---|---|
| Claude Code | Your computers, on your Claude subscription |
| OpenAI Codex | Your computers, on your ChatGPT subscription |
| Grok Build | Your computers, on Grok 4.6 |
| Grok Bot | xAI’s cloud, synced to Tico |
| Hermes | Your Hermes computer, connected over MCP |