Zero To Agent

Reading about agents is easy. Starting is where most people stall.

Not because it's technically hard — it isn't. Because the mental model most people bring to it is wrong, and that wrong model makes every attempt feel broken before it gets going.

So before the how-to: one thing you have to unlearn.

Stop asking. Start assigning.

When you open a chat box, you ask a question. That's the mode. "What's a good way to structure this email?" "Can you explain X?" "Help me think through Y."

That mode doesn't work for agents. You're not there to have a conversation. You're there to hand off a task and walk away.

The shift sounds small. It isn't. Most people who feel like agents "don't work" are actually just asking questions at them instead of assigning work. The model obliges — it answers the question — and the person is underwhelmed because they wanted someone to do the thing, not explain the thing.

Try this reframe: you're not the user anymore. You're the manager. You have a capable person in front of you. Write the brief.

Pick the right first task

Not every task is a good first agent task. A good first task has three properties.

It's repetitive. Something you've done manually more than once and found tedious. Resizing images. Sorting through emails. Pulling data from a bunch of documents into one table. The model shines on tasks where the pattern is clear and the volume is the problem.

It's self-contained. The inputs are clear, the output is clear, and the whole thing doesn't depend on a dozen other moving pieces you haven't explained yet. Don't start with "manage my entire content calendar." Start with "turn these five bullet points into a draft LinkedIn post."

It's reversible. On your first few runs, give it tasks where a mistake is easy to catch and fix. Not "send emails to my entire client list." Not yet. Pick something where the worst case is you review the output and throw it out.

Give it the brief before you give it the task

Here's where most first attempts fail. People paste the task and nothing else. The model does its best with what it has, which usually isn't enough, and the output is mediocre.

Think of it like a job handoff. Before you hand someone a task, you tell them who they are, what they're trying to achieve, and any constraints they need to know. That context lives outside the task itself — it's the standing brief.

In Claude terms, this is called a system prompt or, if you're using Claude's Projects feature, the project instructions. It's a block of text the model reads before every single task in that project. You write it once. It shapes everything after.

A good brief answers: who are you, who am I, what's the goal here, what should you never do, and what does "done" look like.

A weak brief: (empty, or "you are a helpful assistant")

A strong brief: "You are helping me process weekly sales reports. I'm a non-technical sales manager at a mid-sized company. Your job is to pull out the three biggest movers — up or down — and write one sentence explaining each. Plain English only, no jargon. Don't give me summaries. Give me highlights and a recommended next action."

Same model, same task. Different output.

Let it run. Check in once.

The impulse when you first run an agent on a real task is to hover. Refresh. Read every intermediate step. Steer constantly.

Resist it.

The whole point of an agent is that it can run the loop without you in it. If you interrupt every three steps, you're not using an agent — you're doing the task yourself and outsourcing the typing.

Give it the task. Set a rough checkpoint: "When you're done with the first pass, pause and show me what you have before moving on." That's it. Then do something else. Come back when it surfaces.

If it gets stuck and asks a question, answer it and let it continue. That's not failure — that's the model hitting a genuine ambiguity and being honest about it, which is exactly what you want.

What to do when the output is wrong

It will be wrong sometimes. That's fine. The question is how you respond.

Most people go back to the start. Wipe the slate, try again with the same vague prompt and hope for better luck. That's the chat-box reflex.

Instead: treat bad output as information. What specifically went wrong? Was the format off? Did it misunderstand the goal? Did it skip something? Find the gap and fix the brief.

If it got the tone wrong, add a tone instruction to the brief. If it went too broad, tighten the definition of "done." If it hallucinated a detail, add a constraint: "Only use information I've given you. Do not invent."

Each correction makes the brief better. The brief is a program. You're debugging it.

The three-run rule

Here's a practical target: run the same agent task three times before you judge it.

First run: expect rough output. You're learning what the model defaults to and where the gaps are.

Second run: fix the biggest thing in the brief. See if it improves.

Third run: the output should be close to usable, or you should understand exactly why it isn't.

If it's still broken after three deliberate iterations, the problem is usually that the task isn't well-defined enough — not for the model, for you. Defining it more clearly for the model forces you to define it more clearly for yourself, which is rarely wasted.

Where to actually start

If you have a Claude account, start with Projects. Create one, write a brief in the project instructions, and run a small task inside it. The brief persists across every conversation in that project. You don't lose it when you close the tab.

If you're comfortable with a terminal, Claude Code is worth trying. It has access to your filesystem and can read, write, and execute directly. The tasks it can handle are substantially larger. The learning curve is one afternoon.

Either way: start with one task you already know how to do. That's the key part. If you know what good output looks like, you'll know when the model gets it right — and you'll be able to fix the brief when it doesn't.

One good agent task, done well, is more instructive than ten mediocre experiments.