What we learned handing Claude Code a goal, not a task

Most of what we know about the goal command in Claude Code, where you hand the agent a whole objective instead of a single task, came from runs that failed. We mentioned these learnings in our first post about how we build at Buzzinga. Here they are in full.

Start with the core, nothing else

When we start on a new product idea, we only care about the core. No frontend, no scalability thinking, nothing around the edges. If the core does not work, nothing else matters, so we want the agents to prove the core first.

So a goal we write covers what we want to build, what the flow should be, how to test it, the fixtures to test against, and how to measure accuracy. The agent processes everything from the CLI, runs the tests, and saves the results in a structure we define. If the outcome is good, then building the rest around it is worth the effort.

Every line of the goal matters

Our early runs taught us this the hard way. We explained what we needed in general terms and fired the goal command. It touched all the areas we care about, but not in real detail, and it did not cover the edge cases. The agent did not do a good job. This was on Opus 4.8.

What works is breaking the overall task down the way we would build it ourselves. The steps, the pipeline, how we would process the data at each stage. If we cannot write that down, the agent is not going to infer it. A goal written in general terms gets a general result.

Put the plan in a file, not the prompt

Once we understood that, we did the research first, all the detail work up front. Then we asked Claude to turn it into one prompt we could use to build the whole thing, and it gave us a long one.

We fired it as a goal and it failed silently. No error we could see, just nothing useful happening. It took us a while to figure out why: goal prompts are limited to 4,000 characters. That was news to us.

The fix was simple. We put all the research into a markdown file in the repo and ran the goal as "implement this file". The goal itself now only needs to carry the pointer, not the whole plan. This is how we run every goal now.

Separate a bad goal from a model ceiling

With the plan in a file, the input was right, and the result was still not great. The setup was no longer the problem. The model was the ceiling. Still Opus 4.8.

About a week after that experiment, Fable 5 became publicly available. We ran the same goal with the same markdown file, nothing changed on our side. The results were far better than any of our earlier runs. Not perfect, but a clear jump. It built the core, ran the tests against the fixtures, and saved results we could actually evaluate.

The insight we kept from this: when a run goes wrong, work out whether the goal was not clear enough or the model could not do it, because the fix for each is completely different. Detailed goals turned out to be necessary but not sufficient.

Give the agent a way to check its own work

This is the one thing we would not remove from any goal now: a way for the agent to evaluate what it is building while it builds it. Tests it can run, fixtures to run them against, a defined structure for saving results, and a measure for accuracy. With that loop in place, the agent tweaks during implementation instead of us discovering the problems after it declares itself done.

It is the same principle as the docs we keep inside our codebases, which we wrote about in the first post. Docs give the agent the right context going in. The evaluation loop gives it the right feedback while it works. It needs both.

Where this leaves us

We are still figuring out how big a goal can get before it needs to be broken into several. Core-only objectives with a clear evaluation loop are working well for us now. We have not pushed much past that yet, and we will write about it when we do.

If you are experimenting with goal-sized objectives yourself, we would genuinely like to hear how it is going.