TL;DR
- The Principle: When AI output misses, the problem is usually the input. The fix is better direction, not a different model.
- Specificity: Element-level notes and screenshots beat “make it look like this site.” Describe the navbar, the header, the interaction.
- Reverse Prompting: Ask the agent what tools, API keys, and access it needs to run on its own. Capable agents request capabilities.
- Autonomy: A bounded objective, a no-interruption rule, and a defined escalation path turn a chatbot into a worker.
- The Economics: A few hundred dollars a month in agents can do work that used to require a full-time hire.
I keep a close watch on solo founders who are outbuilding funded teams with AI, because they expose where the real edge is. The best case I have followed in months is a founder with no engineering background who shipped a paid SaaS product and signed paying customers while a venture-backed competitor in the same niche raised tens of millions. His entire operation runs on a few hundred dollars a month of AI tooling.
Nothing about that outcome came from a better model. Early on he burned through credits producing nothing shippable, and his first instinct was the same as everyone’s: blame the AI. The turning point was a single reframe, and it is the most useful idea in AI work right now. When the output is bad, the problem is almost always the input. The model acts on the context, constraints, and instructions you give it. Miss on those and no upgrade fixes it.
That reframe applies far beyond software. Once AI made production cheap, editorial judgment became the only moat left, an argument I have made about content before. This founder proved the same principle governs product direction, design taste, and every other place AI touches work. Here is the framework, stripped of the story.
Bad Output Is a Direction Problem
Most teams respond to weak AI output by shopping for a new tool. The tool was rarely the problem. Generic output is the predictable result of a generic brief: no reference material, no standards, no constraints, no definition of done. The AI does not know what good looks like because nobody told it.
I see this failure every day in content operations. Teams point an engine at a topic and call it a strategy, then blame the model when the drafts read like every other AI draft on the internet. The fix is identical to the one I documented in my content quality stack: constraints, reference material, and taste standards go in before generation starts, not after the output disappoints you.
Here is the mental model that makes it stick. Treat the AI as a fast, literal contractor. A contractor given “make something good” delivers random quality. A contractor given a spec, samples of work you admire, and a list of failure modes delivers something you can use. The difference is not talent. It is direction.
Practice 1: Give It Ground Truth, Not a Name
The most common direction failure is naming a destination instead of describing it. Telling an AI “make it look like this site” is not a spec. It is a guess the AI has to make about which parts of that site matter to you.
The fix is to describe what you want, element by element. When this founder wanted a design reference, he did not paste a URL. He wrote notes: I like this navbar, I like how this header handles the logo, I like this spacing between sections. Then he took it further and screenshotted everything he liked and handed the images to the agent.
That combination is the real difference. Screenshots give the model visual ground truth. Element-level descriptions give it intent. Most people give AI neither and then blame it for guessing. The same rule applies to prose. An editor who says “write like our best posts” gets nothing. An editor who includes two best posts, the audience definition, the house style rules, and three examples of what to avoid gets work that needs light editing, not rewrites.
The principle generalizes: before you judge any AI output, ask whether the input contained enough specificity to succeed. If the reference was a vibe instead of a spec, the skill issue was yours, and that is good news, because it means the fix is in your hands.
Practice 2: Reverse the Prompt
The second practice inverts the direction of instruction. Instead of trying to know everything the agent needs up front, ask the agent what it needs to do the job completely.
The question sounds like this: what tools, API keys, and MCP servers do you need to be fully autonomous? Model Context Protocol is the standard that lets an AI agent connect to external services, and it is the difference between an agent that chats and an agent that does.
In the case I followed, the agent needed to research competitors and could not capture what it was seeing. Told to solve that itself, it identified the missing capability, found a browser-control tool, and came back able to open pages, click through flows, and take screenshots. That single capability turned the agent into a research department: it pulled user reviews, clicked through a competitor’s product, and documented the exact gaps to build for.
Most users never get here because they treat a stuck agent as a dead end. They either abandon the task or hand-hold it through every step. The better reflex is to treat the blocker as a missing tool and let the agent tell you what it needs. An agent that can request capabilities instead of failing silently is an agent you can eventually trust with a business function.
Practice 3: Objectives, Not Scripts
The third practice is the difference between automation and agency. Automation follows a flow you designed. Agency takes an outcome you defined, chooses the path, and comes back only when it is genuinely stuck.
| Automation | Agency | |
|---|---|---|
| Input | A flow you designed step by step | An outcome you defined |
| Failure handling | Breaks and waits for you | Finds the missing tool or escalates |
| Scope | One task, repeated | Any task inside its role |
| Your attention | Required constantly | Required only at decision points |
Three ingredients produce agency, and they are worth copying precisely. First, a bounded objective: the agent knows what done means. Second, full tool access: it can act on the objective instead of describing how it would act. Third, an escalation path: it pings you only when it truly needs a decision, and it keeps working until then.
Agents run this way stop asking for permission and start surfacing judgment calls. In the case I studied, the founder was so focused on shipping that he had never installed analytics. His agent flagged it before he did, recommended PostHog, and built the implementation while he watched. A scripted automation would never have noticed. An agent with an objective did, because missing data was a threat to the outcome it owned.
What a Real Agent Stack Costs
The economics are the part most executives do not believe. The entire operation I have been describing runs on roughly $400 a month: a coding agent for the build work, an overflow plan for heavy days, infrastructure for data and hosting, and a free analytics tier. The founder estimates the same work would cost $50,000 to $70,000 a year as one department, and he is not exaggerating. I run a comparable structure inside my own business, and I documented the architecture in From One Automation to Eight AI Agents and in the post about how my AI chief of staff runs day to day.
This is not a software-only story. Any content engine, CRM, or pipeline running on AI workers faces the same choice: keep treating the models as search bars, or define roles, give them memory, and let them own outcomes. The teams that measure whether AI moved a metric instead of whether it produced output are the ones that will see the return, which is the shift I wrote about in my piece on measuring AI impact instead of output.
What I Actually Think
Every time one of my agents ships something mediocre, my first instinct is still to blame the model. The rule above applies to me too: did I give it the source briefing, the editorial standard, the audience context, and the constraint list before it started? In the cases where the output is genuinely good, the answer is always yes. When it is not, the failure is always upstream of the model.
Every mediocre AI output I have shipped traces back to an input I under-invested in. The model was never the weakest link. Direction was.
The practice I am stealing first is the autonomy rule. My best work happens when I give an agent a bounded objective, the tools it needs, and a clear escalation path, and then stop interrupting. The discipline is harder than it sounds, because every interruption feels productive in the moment. It is not. It is a tax on the agent’s ability to develop judgment.
If you are still treating AI like a search bar, that is the skill gap to close, and it is closable. None of this requires a technical background. It requires the same thing good management always required: knowing what good looks like, saying it clearly, and getting out of the way.
Bad output is a direction problem. Before you switch tools, upgrade the brief: context, constraints, reference material, and the authority to ask for what the work needs.
If you want to build an AI operation that ships work instead of drafts, my inbox is open. Tell me where your current output is falling short, and we will figure out whether the problem is the tool or the direction.
