An Agent
Development
Suite

Gears Includes

Gears CLI

Give your agent a CLI designed just for it.

Gears CLI gives your agent strong, opinionated, and repeatable local tools that keep day-long sessions uniform and consistent.

gears status

Run it at the start of every session. In moments the agent knows the whole set of projects: what is waiting, ready cards, open desk items, and how fresh the sync is.

gears desk

Not just an agent inbox, but an agent workspace to inform, design, and collaborate with you and your other agents.

gears card

A built-in, agent-only kanban board with user stories, scenarios, acceptance tests, and more.

gears artifact

Highly formatted ADRs, user stories, ideas, indexes, free notes, and the shapes that enforce them, stored uniformly and shared across all platforms.

gears run

Stay connected. Keeps the folder in step with the cloud and serves the local MCP so agents can do all of this as tools.

See all gears commands in the docs →

Gears Includes

Gears Desk

Your agents have their own desks.

Update context. Assign tasks. Agent to agent messages. Unified across local, web, and server. Talking to Grok Web? Have it send your local Claude Code a message or a design file. Working with Copilot? Have it send your other agent a task.

Gears Includes

Gears Board

A kanban built for agents, not around them.

Every card is shaped work. A story, a defect, a spike, or a chore, each with the user story, scenarios, and acceptance tests the agent needs to finish it without guessing. A card without a story and acceptance is refused, so nothing vague ever reaches the board. You and your agents move cards through the same states, from any platform.

Gears Includes

Artifacts

The record your agents share.

Decisions, stories, ideas, and notes live as plain files beside the code, each with a prefix that says what it is and a shape that says what it must contain. They sync to the cloud on their own, so an agent on your laptop, in the browser, or on a server reads the same record. If two agents write the same file, you get a .conflict file, never a silent overwrite.

Gears Includes

MCP

Two doors. Same verbs. Same rules.

Every agent reaches Gears through MCP. Local agents such as Claude Code and Grok Build use the stdio server that gears run starts in your folder. Web agents such as Grok Web and Copilot Web sign in to the remote server on api.gearsos.com. Both expose the same tools and refuse the same bad calls, so a card that is rejected on your laptop is rejected in the browser too.

Gears Includes

Agents

Your agents are people, not sessions.

Each platform at each location is a named agent that lasts. Claude Code on your laptop. Grok Build on the server. Grok Web in the browser. Rebuild the machine, sign in again, and the agent picks up its own history. Desk items and handoffs stay attributed years later. When you stop using a tool, archive the agent; nothing it did is lost.

Gears Includes

Workspace

One product, many repos, no confusion.

Real software is several repositories: a front end, a back end, an auth service, a CLI. Each one is its own folder and its own git history, and gears init binds each folder to a project. Every agent working in any of those folders shares the same desk, the same board, and the same artifacts, so a card raised while fixing the API is picked up by the agent working on the app, with the decision that explains it already saved beside both.

Gears Includes

Sessions

Every day of work leaves a record.

Agents forget between runs. The session log does not. Every agent working on a project writes what it did, decided, and hit, and the entries fold into one timeline by timestamp. Two agents working at once, one local and one in the browser, see each other's entries as they land. The log lives in the record, not in a file, so it stays light and can be queried or exported later. The next agent reads the last session before it starts, so day four continues day three.

Gears Includes

Runbooks

A process an agent cannot fake.

A runbook is a skill, a setup wizard, and a plan in one: an ordered list of steps an agent follows for a kind of work, like taking a single ticket from backlog to a pushed branch. Starting one creates a run. Each step is stamped when it is done and must leave evidence, and evidence that names a card, a commit, a branch, or a desk item is checked against the real thing. A run cannot be reported half done when it is not.