Lesson 12.812.8 The same agent outside the app

In everyday life. A taxi driver can take bookings at the taxi stand, through the app on their phone, or from a regular customer who calls every Monday at 7. The driver, the car and the rules of the road are the same each time. Only the way the job arrives changes.

What you will learn. How the same agent runs from a terminal, an editor, a script and a pipeline, and why a seat with fewer people watching needs tighter limits.

Why it matters. A run that nobody watches cannot ask you anything. What it may do has to be decided before it starts.

Where else can it run?

So far you have started the agent in the desktop app. The agent is the driver, and each place you can start it from is a seat, where you sit to give it a job. This book starts in the desktop app because it puts the pieces in one place: the folder picker, the list of sessions, the permission prompts, every change line by line, and the local or cloud choice. The same agent also runs in four other seats.

Figure 12.8. One agent, five seats. In every seat, check the project, the instructions loaded and the permissions. Less supervision calls for tighter permissions and clear stopping rules.

What stays the same?

The driver and the rules of the road. The rules file travels with the repository into every seat, so the agent can follow the same project rules whether you start it from the app or a pipeline. Settings files travel too. But a seat does not always load them. Some headless modes skip the rules file on purpose, for speed or for a clean run, and 12.7 names one. So check that each seat loads the rules and settings you intend.

What changes when nobody watches?

Nobody is there to say yes. In the app, a risky command waits for you. In a script or pipeline, the permissions must be set in advance, and set tighter: which tools the agent may use, which commands it may run, and which folders it may write. A headless run should have the least it needs. A run that reviews pull requests needs to read and comment, not to push to the main copy.

Nobody is there to say "done", either. So give the run a condition that ends it, such as "all the tests pass". Some agents can have a second model check that condition after each turn (12.7 names one). That model reads only the conversation, and it runs nothing itself. So its "done" is a second opinion, not your check. As 12.1 showed, passing tests show only that the script runs.

How does a program read the result?

A person reads the agent's answer in the app. A script needs output it can read. Headless modes can return structured output, in a fixed text format programs read, such as JSON, so the next step of a pipeline can check what happened. Some can also stream each step as it happens, so a program can show progress or stop a run early. Chapter 24 teaches structured output in depth.

What is a routine?

The same agent with the same rules file, started by a clock or an event instead of by you. Some products can run a saved task in the AI vendor's cloud, on a schedule or when an event arrives. The event can be a new invoice file or a webhook, a message one system sends another when something happens. These are often called routines or automations. Chapter 29 builds them.

At work. Ana's team now opens every change to brightline-ap as a pull request. A pipeline runs the coding agent headless on each one. It reads the rules file, runs npm test, checks the change against the rule about data/, and posts its comments. It can read the code and comment, but it cannot change what it reviews. Each run also runs the cases from Ana's check, which, once the script was right, she turned into tests. Its comments are one worker checking another. As Chapter 6 says, that is not a review, so a person still decides. Chapter 15 builds this review setup in full.

The operating rule: keep the rules in the repository, check that each seat loads them, and the fewer people watching a seat, the tighter its permissions must be.

Practice it. Practice: outside the app, in your own tool, ten minutes, plus the command-line install.