How to Use Agents in Real Work: An Overview
Using AI agents at work starts by splitting roles with the search box. Search collects explanations. An agent acts on files, terminals, and browsers. This overview covers what to hand off and what a person still reviews. No product reviews or prices.
The scope is “what to pass and what to read.” Install flags and pricing belong in tool-specific posts and official docs.
How is this different from a search box?
One-line answer: Search (or plain chat) answers a question. An agent takes a goal, a scope, and a done-definition, then moves in a repo or a document set.
Search-shaped use is usually one turn. “What is this error?” or “How do I build a pivot?” returns an explanation and links. Copy-paste and apply stay human.
Agent-shaped use is a job. You pass target paths, what not to touch, and the artifact to show when finished (a diff, a table, a draft). ADE and CLI agents can attach worktrees, terminals, and a browser, so you get changes and logs, not only an answer.
The usual confusion is treating a smart search box and an agent with write access as the same window. Keep read-only research in search or Ask. Promote to Agent or a worktree only when files will change. Wider permission means a wider review bill.
A compact split:
- Search/chat: concepts, API names, error reading, draft ideas.
- Agent: reproduce, patch, run tests, write a draft to disk, repeat a refactor.
- Human: lock the goal, secrets and auth, merge, outbound wording.
What work do you hand off?
One-line answer: Start with closed-scope work whose inputs and outputs are files and whose failures are cheap to revert.
Good first jobs:
- Closed bugs with a repro and a failing log. “Candidates for the flaky login test and a minimal patch.”
- Mechanical transforms: formatting, import cleanup, test scaffolds, lifting comments into an outline.
- Read-then-summarize: read only named directories; return a table or checklist. Turn writes off or use a separate worktree.
- Drafts: commit messages, PR text, meeting-note skeletons, slide outlines. Final wording stays human.
Too early:
- Directories with production secrets, payments, auth, or personal data.
- Open requests such as “make the codebase better.”
- Deploy, force-push, or permission changes — expensive to undo.
Pick tools by execution surface, not brand. A chat-only window, an IDE with a local diff, and an ADE that splits worktrees are all “agents” with different blast radius. A common pattern is bring-your-own: attach a CLI subscription you already have.
When several agents run at once, give each one goal, isolate writes per worktree, and let one person integrate. Parallelism is a decision about where collisions land, not only about speed.
Where does a person still review?
One-line answer: Goal and bans before start; permissions and logs during the run; diff, facts, and tone before you call it done; tests and secrets before merge.
Pin review to checkpoints, not a vibe.
- Before the prompt: one-sentence goal, target paths, bans (other packages, repo-wide formatter, remote push). Make done observable (“test X passes”).
- During the run: a human approves network, sudo, or production credentials at that moment. If logs stall, read the output before re-prompting from a guess.
- On the artifact: source diff, numbers and citations, outbound copy. Agents write fluent sentences and can embed a wrong figure in the same paragraph.
- On integrate: parallel work collides when branches meet. Rebase/merge and CI stay human-owned.
Splitting read-only research from write sessions cuts review. “Just fix it” is the search habit attached to write permission. On failure, narrow the same goal, or re-assign only the repro and write the patch yourself.
The next step in this series is turning search questions into work units. A written role split matters more than an extra click in a tool.
Sources
- Role model is shared across the series (search → instruction → review). Product commands follow that product’s official docs.
- Orca ADE context: What is Orca?, Worktrees