You now know how to start an AI CLI session, understand basic commands, run an app locally, inspect logs, install an approved dependency, use a visible workbench, choose an appropriate model, and protect a feature with Git and a branch. This lesson puts those pieces together.

A GUI chat usually encourages one conversation and one task. A CLI workspace gives you something more useful: several focused work surfaces at once. One terminal can run your local website. Another can run tests. A third can let Codex build a feature. A fourth can let Claude review a specification or research a question.

That is orchestration: directing several pieces of work so they move toward one outcome without colliding.

The terminal also reaches beyond the project folder. Once you install and authenticate a service's CLI, that same workspace can become a controlled connection to the services that run your product. An AI agent can inspect and propose work against those services through their official tools instead of making you hunt through five different dashboards.

More tabs do not automatically mean more progress. Four agents editing the same files with vague instructions create confusion faster than one agent can create value. The human job is to divide the work, set boundaries, and decide when the pieces are ready to join.

The useful multi-tab workspace

One project folder and its contextTerminal 1: local web appTerminal 2: build taskTerminal 3: research or reviewTerminal 4: tests and logsHuman director: inspect and decide

Each tab should have a role. A good starting layout is:

The important phrase is single job. A terminal that is running your website should not also be the place an agent is deleting dependencies. A reviewer should not quietly become a second builder. Clear roles keep the evidence readable.

The terminal can be your service control room

Your coding agent does not only understand a language model. It can use any command-line tool installed on your machine. That means one task can move from code to the real services behind that code—provided you have installed the official CLI, authenticated it, and approved the scope.

A CLI can do much more than write code

A CLI gives an AI a way to work with the real environment around a project: files, folders, commands, servers, logs, databases, and the tools developers normally use to set things up and repair them.

When a browser-capable AI integration or computer-use plugin is available alongside a coding agent, the reach becomes bigger. The browser side can navigate a service dashboard; the CLI side can create project files, run commands, install an approved package, read an error, and test whether the pieces now work together. Each surface has a job, and you still control the permissions.

Imagine you want to create an AWS server or database but do not yet know the AWS console. An AI can help you understand the console workflow while the CLI agent prepares the application, connects it to the database, runs setup commands, checks configuration, and helps diagnose errors. You still decide which account, services, permissions, and spending you authorize.

That is a powerful example of what a CLI is for: it gives the AI practical hands inside the technical workflow, not just a chat window that can describe what you should do. The same principle applies to the service CLIs below.

Human sets task and approval boundaryAI CLI agentGitHub CLI\nbranches, issues, pull requestsVercel CLI\ndeployments, logs, environment variablesSupabase CLI\nmigrations, database, storageCloudflare CLI\nworkers, DNS, deploymentsOther service CLIs\nresearch, data, operations

The important idea is not that an agent gets unlimited power. It is that you stop treating every dashboard as a separate manual chore. The agent can read the project context, inspect the relevant service through its CLI, make a plan, carry out an approved change, and return the command output as evidence.

You will meet GitHub, Vercel, Supabase, and Cloudflare in the build-software and deployment lessons. Here, learn the pattern: install the official CLI, authenticate deliberately, give the agent one bounded job, inspect the result, and record what changed. The command is the bridge between the project and the service.

Authentication is a boundary, not a blank check

Authentication lets the CLI act as *your* account. It does not decide what should happen. A token may be able to change a production setting, create a database migration, add an environment variable, or alter DNS. That makes these actions fast—and worth treating as explicit approval moments.

Before an agent performs a remote action, tell it the environment, exact target, and stop point:

Inspect the Vercel project linked to this repository and explain why the latest preview deployment failed.
Do not change environment variables, redeploy, promote to production, or alter project settings.
Return the relevant logs and the smallest proposed fix.

Then give a second, specific instruction only after you understand the plan. “Set PUBLIC_ANALYTICS_ID on the preview environment, show me the result, and do not touch production” is clear. “Fix Vercel” is not.

Some CLIs touch money or markets

New CLIs arrive constantly, including tools for marketplaces and prediction markets such as Polymarket. These can be useful for collecting public market data, comparing scenarios, or building research workflows. They can help an agent *inform* a trading decision.

They should not turn into unattended financial action. An AI can misunderstand data, follow bad instructions, or use the wrong account or market. Keep trade placement, withdrawals, account permissions, and spending limits behind your direct review. For money-moving commands, require the agent to prepare the analysis and exact proposed action first; you make the final decision.

Give every agent a task brief

An agent does not need a novel. It needs a bounded assignment.

# Task: review the comparison-page specification

Read: README.md, CONTEXT.md, and docs/comparison-spec.md.
Do: identify missing user cases and unclear acceptance criteria.
Do not: edit source code or create a branch.
Return: a numbered review with the three most important gaps.

Compare that with “look at the app.” The brief tells the agent where to start, what it owns, what it must not touch, and what a useful answer looks like.

Parallel work needs separate surfaces

Use the following rule:

Branches protect the project history. Separate folders or Git worktrees protect the working files. You do not need to use the advanced tools on day one; you do need to recognize that two agents writing into the same file is not parallelism—it is a collision.

Orchestration is a loop

1. Choose the outcome. 2. Break it into independent tasks. 3. Give each task a clear owner and boundary. 4. Let work happen in the right tab or branch. 5. Review outputs before combining them. 6. Record the result in Git and HANDOFF.md.

The human remains the integration point. You do not need to read every line of code before anything happens, but you should know what each agent was asked to do and what evidence says it worked.

Practical exercise: make a four-tab plan

For one small feature, write a tab plan before opening an agent:

1. What stays running? 2. What will the builder change? 3. What can a reviewer or researcher do without editing files? 4. What test proves the work is ready?

Start with only two tabs if four feels excessive. The goal is clarity, not maximum activity.

Check your understanding

1. What is orchestration in an AI workspace? 2. Why should each terminal tab have one clear role? 3. When do two agents need separate branches or worktrees? 4. Who decides when separately completed work can be combined?