Agents have moved out of the chat window. They now have their own computers, tools, and schedules. Here's how we use coding agents, MCP tools, and Grok Bots in our own work and in client products, and the guardrails that keep them useful instead of risky.
For most teams, AI help used to arrive as a chat window: ask a question, copy the answer, do the work yourself. That's no longer the shape of it. Coding agents edit whole repositories and run the test suite. Tool protocols let a model drive a browser, query a database, or read a chart. And products like Grok Bot give an agent a name, a job, a persistent cloud computer, connected apps, and a schedule, so it keeps working after you close the laptop. The question founders bring us has shifted from 'should we use AI?' to 'which jobs can we safely hand to a bot?'
Our own delivery runs on coding agents, and the biggest lesson is that the spec is the leverage. Agents are fast at typing; they're only as good as the instructions they get. So we write specs as hand-off documents: a locked architecture, the exact calculations, acceptance tests, explicit non-goals, and a short section of notes for the agent — where business logic lives, which security rules are non-negotiable, what to show when data is missing. Repo-level instruction files carry the house conventions from one session to the next. That's how Wheel Desk went from first commit to a public beta in under two weeks without cutting corners on security.
An agent is only as useful as the tools it can reach, and the Model Context Protocol has become the standard way to hand them over. An MCP server turns a system into a set of functions an agent can call. In a normal week, our agents drive a real browser to reproduce bugs and check layouts, pull design context from Figma, inspect a Supabase database, and work against TradingView Desktop through an MCP bridge that reads chart state and compiles Pine Script. Model APIs are moving the same way: xAI's API can run web search, X search, and code execution as server-side tools, and call remote MCP servers directly.
Grok Bots take the next step: durable agents you manage like a small team. Each Bot gets a job, its own conversation and memory, a persistent computer with a browser, and plugins for services like Gmail, Slack, GitHub, and Notion. Skills capture a workflow once so any Bot can reuse it, and routines run that workflow on a schedule or when an event arrives, such as a Slack message or a GitHub notification. The jobs that work best are narrow and recurring: reproduce every new bug report in a browser and attach the steps, prepare the Monday metrics digest, sort the support inbox into drafted replies, or watch competitors' changelogs and summarize what shipped.
Write the job in operational terms. 'General helper' is the worst title a bot can have: it gives the model nothing to aim at and makes its memory hard to reuse. A good description reads like a role at a real company — what the Bot owns, which sources it uses, what it produces, and what it must never do. 'Own weekly bug triage. Reproduce each new issue in staging, attach steps and screenshots, and label severity. Never close an issue or message a customer.' Start with one Bot that owns an end-to-end outcome, and add a specialist only when the work has a stable role of its own.
Then draw the approval boundary. Our rule for every agent we deploy, whether it's a Grok Bot or a custom build: bots prepare, people commit. Let the bot research, draft, reconcile, and recommend, and require a person to approve anything that sends, buys, deletes, publishes, or changes production. Give every routine a policy for missing and stale data, make retries idempotent so a rerun can't double-post, and tell the bot where to report partial work. Memory isn't a source of truth either. Consequential decisions should re-open the source system, not trust what the bot remembers from last week.
When a bot touches money, we go further and keep the model out of the decision entirely. In Wheel Desk, contracts are filtered, scored, ranked, and sized by deterministic code with its weights in a config file. The most a language model may do is write one sentence explaining a pick from the stored fields, with a template as the fallback when the model is down. Bots we've built around trading follow the same shape: strategy logic that never talks to the broker directly, a separate risk layer with hard limits and a kill switch, and a person approving anything irreversible from their phone.
Finally, treat models and tools as replaceable parts. Put model calls behind a thin adapter so a bot can move between Grok, Claude, and GPT models when price, speed, or quality shifts, because in 2026 that happens every few months. Tool calls are metered, so routines need budgets and logs like any other production job. If you're considering agents for your product or your team, start small: one bot, one job, one approval boundary, and a log someone actually reads. Earn the second bot. That's how we scope agent work for clients, and it's how we run our own studio.