CLI wrapper: what to borrow from Firstmate AI

Why it matters

An agent can complete a task while still leaving you with most of the coordination. It asks which repository to use, retrieves too much data, misreads an empty response, then needs help choosing its next command. A CLI wrapper can package those recurring decisions into a predictable interface.

What interests me about Firstmate AI is the explicit machinery behind that interface. The project combines instructions, scripts, and conventions to coordinate coding agents; its repository is the distribution of that working environment. It makes operational choices visible enough to inspect and question. Official Firstmate repository.

My starting point would be one recurring task with a measurable failure pattern. I would want evidence that a smaller interface reduces my involvement before adopting the wider orchestration system. This is an architectural assessment based on the video and documentation. The experiment below is a proposed way to evaluate the idea in your own workflow.

Key points

• 01:16 The repository supplies the working environment. Instructions and scripts specialize a general coding agent. That makes configuration inspectable and turns it into another part of the software someone must maintain.
• 01:55 Delegation comes with explicit responsibilities. In the version shown, the coordinator leaves project edits to workers and integration requires approval. Preserving unfinished work is another important part of that agreement.
• 04:20 The coordinator prepares an execution brief. Context and acceptance criteria travel with the assignment. This gives a worker a result to demonstrate rather than an open invitation to change things.
• 06:45 Three concurrent assignments demonstrate the coordination model. Separate working directories organize the changes. The demo explains how work is dispatched without establishing a general productivity gain.
• 08:39 The supporting interfaces are designed for agents. AXI tools shape information around decisions the agent needs to make. Some operational knowledge moves from prompts into executable behavior.
• 09:15 Routine supervision becomes deterministic code. The watcher described follows events without repeatedly invoking a model. That saving applies to monitoring; the workers still consume model resources.
• 11:42 A wrapper can eliminate repeated discovery. The GitHub example adds selected fields, counts, and suggested next steps. A fair evaluation should also include a carefully configured native CLI call.
• 13:32 A personal requirement can justify a new interface. The overcf example illustrates building a CLI around an API. The following browser example highlights errors that explain how an agent can recover.
• 15:22 Delivery gets a validation stage. The no-mistakes pipeline organizes checks before work proceeds. Its usefulness depends on what those checks can actually establish.
• 17:16 Shared conventions require editing over time. Reusable instructions reduce repeated discovery, while accumulated rules can introduce contradictions and unnecessary context.
• 19:42 Maintenance changes the economics. API changes, dependencies, and inherited assumptions can consume the initial savings. Usage frequency matters as much as implementation speed.

How to apply

Start your CLI wrapper with a read-only task

Pick a recurring operation such as finding pull requests waiting for your review. Define a successful result before implementing anything: the correct repository, matching items, and a clear indication when more results exist.

Watch a few ordinary runs. Record where you intervene. Does the agent choose the wrong repository, miss another page, or interpret an authentication failure as an empty list? Those observations should determine the wrapper’s scope. A read-only starting point lets you evaluate information handling before introducing remote changes.

Establish a useful native baseline

Configure the existing CLI to return only the fields and records needed for the task. A large response may reflect an overly broad command rather than an interface that needs replacing.

Then identify what custom code would add. Useful additions might include resolving team-specific names, applying a recurring filter, handling pagination, or distinguishing states that currently cause confusion. If field selection fixes the problem, a small script may be enough.

AXI provides useful design prompts here, including explicit empty results, structured errors, and information that removes follow-up queries. I would treat each as a hypothesis about my workload and measure the effect. Official AXI principles.

Define the contract before asking an agent to build it

Suppose you create a command called review-queue. This is an illustrative interface proposed here, not a command demonstrated in the video. A minimal contract could look like this:

| Condition | Required response | | --- | --- | | Completed query | Repository identity, matching items, and returned count | | No matching items | Explicit success with a zero count | | Additional page available | Continuation indicator and a way to retrieve it | | Invalid authentication | Recognizable error and access recovery guidance | | Temporary failure | Recognizable error that preserves the query’s incomplete status |

Specify an output limit, timeout behavior, and treatment of unknown arguments. Keep examples small enough that a teammate can understand the interface without reading its implementation.

When adding writes, define retry behavior separately. A lost connection does not establish that a remote operation failed. The agent may need to check whether the change happened before repeating it. This becomes especially important for operations that create comments, tickets, or other duplicateable records.

Evaluate process boundaries separately from Git organization

A worktree supplies another working tree linked to a repository and shares parts of Git’s underlying structure. It does not, by itself, restrict what a process can access on the machine. That distinction matters when assessing the autonomy shown in the video. Official git-worktree documentation.

For the pilot, use test data and credentials scoped to the task. If an agent will execute code unattended, decide how its filesystem access and external connections will be limited. A successful check at the end cannot reverse a remote action performed earlier.

Also define the evidence required for delivery: a reproduction of the original defect, relevant checks, and a reviewed diff. A tool such as no-mistakes can organize that handoff, while the project owner remains responsible for choosing meaningful criteria. Official no-mistakes documentation.

Count attention recovered and maintenance incurred

Run ten comparisons on equivalent tasks using similar model settings, permissions, and acceptance criteria. Track successful outcomes, human interventions, elapsed time, available cost data, and minutes spent repairing the wrapper. Ten comparisons can guide a pilot; they do not establish a universal benchmark.

Consider a hypothetical result. Twenty weekly uses save four minutes each, recovering eighty minutes. Maintenance consumes twenty minutes, leaving one hour of weekly benefit. A six-hour implementation would take six weeks to recover its initial time investment, assuming usage and savings stay constant.

Schedule a decision after two weeks. Keep the wrapper if it reduces intervention while preserving result quality. Narrow its scope if maintenance absorbs the gain. I would add another integration or multi-agent coordination only after seeing that evidence. Give every added tool an owner, a few usage examples, and a clear condition under which it should be retired.