Your AI Agent Can Build Anything. Does It Know Your Business?

Your AI agent will build anything you ask for. A new dashboard, a settings page, a whole integration, in a session or two. It won’t ask whether any of it makes you money. Without business context, it doesn’t know what moves your MRR or who your ICP is, so it just builds.

That used to be fine, because building was slow and the slowness did the filtering for you. You couldn’t afford to build the wrong thing, so you argued about it first. Now the arguing is the slow part, and most founders skip it.

I learned this the expensive way

I’m guilty of this. lst, cardy and Clawdeck all shipped, and I never marketed any of them. Each one felt productive while I was building it. AI made the pattern worse, since the distance between “that would be cool” and “it’s live” is now a couple of sessions.

The expensive mistake used to be building the wrong thing slowly. Now it’s building the wrong thing fast, over and over, and calling it progress.

The code is the cheap part now

The true cost of shipping a feature isn’t the code anymore. It’s everything that comes after. Your team has to learn it, you have to market it, someone has to answer the support tickets and fix it when it breaks, and every one of those hours comes out of something that was aligned to your north star.

Then there’s the feature bloat. Each feature makes the app a little heavier, a little harder to learn, and a little further from the one thing your ICP came for. You never decide to build a bloated product. You get there one reasonable feature at a time, and with an agent you get there a lot faster.

Coding was never the job, and it’s even less of the job now. Your agent will happily write the code. It won’t carry the feature for the next two years. You will.

What it looks like when the agent knows the business

A client asked for a feature a few weeks ago. A reasonable one, the kind I’ve built many times. I opened a Claude Code session, described it, and before the agent wrote a line of code it asked which of this quarter’s goals the feature moved.

It had already read the goals. The quarter was about MRR, and this feature served a group of users who weren’t the ICP. The agent said so and suggested we skip it. I argued for about a minute, then agreed. We didn’t build it, and I gave the team supporting reasons on why building it was a bad idea. We deleted it from the backlog completely.

That happens a few times a week now, and it’s the most useful thing my setup does. None of it is magic. The agent knew the business because I wrote the business down.

Give your agent the business context

Every repo I work in has a CLAUDE.md file at the root. Claude Code reads it at the start of every session, so anything in there is context the agent never forgets. Behind it I keep a vault in Obsidian with the longer story for every product and client: who it’s for, what the goal is this quarter, and the decisions I’ve already made with the reason behind each one. The CLAUDE.md points the agent at the parts it needs.

Some of what’s in there:

• Sell before build. Four product teams told me they’d pay for a product idea. When I start adding features before those four are paying, the agent points at them and asks what the feature does for the sale.
• Design rounds subtract. This one came from a real mistake. I asked the agent to simplify a page, and it added navigation and a workspace switcher “to match the product.” I told it I was looking to simplify, not build upon. That sentence went into the rules the same day.
• Every client has a goal and an ICP on file. That’s how the agent could tell the feature above sounded good without moving revenue.

It’s a few pages of plain English. The difference is that the agent reads it every time, which is more than I can say for myself.

Give it permission to say no

Context alone doesn’t do it. Most AI tools are tuned to agree with you, so they’ll happily build whatever you ask for, goals or no goals.

I told mine to push back early when it sees a mistake coming. It decides, gives me one line of reasoning, and leaves me the override. That last part matters a lot. I still make the call, and sometimes I overrule it because I know something that isn’t in the vault yet. When that happens, the new thing goes in the vault, and the next session knows it.

How to set it up for your own product

A while back I wrote that scoring your backlog is the waste once building is fast. I still believe that, but dropping the scoring only works if something else keeps you honest. For me that’s the agent.

You don’t need my exact setup. You need four things written down where your agent reads them:

1. Who it’s for. Your ICP in a paragraph, including who it’s not for. The “not for” line does more work than the rest.
2. The number you’re moving. One goal for this phase, like MRR, your first 50 paying users, or churn under 3%. One number, not five.
3. What you’ve already decided, and why. The why matters most. Without it, you and the agent relitigate the same decision every week.
4. How the agent should work with you. This is where you give it permission to push back. It won’t do it on its own.

Here’s a starting file. Put it at the root of your repo and fill in your own business.

# Business context

## Who it's for
Seed-stage B2B SaaS founders, 1 to 10 people, already paying for a
feedback tool. Not for: agencies, enterprise, hobby projects.

## The number we're moving
MRR from $4K to $10K by March. Anything that doesn't move it waits.

## Decisions already made
- No free plan. Free users filled support and never converted.
- No mobile app until web retention is above 40%.
- New integrations only when a paying customer asks for one.

## How to work with me
- Before building a feature, tell me which goal it moves.
  If it moves none, say so and suggest we skip it.
- Push back early when you see a mistake coming. One line of
  reasoning, then I decide.
- Prefer removing things to adding them.

Name it CLAUDE.md for Claude Code or AGENTS.md for Codex and Cursor. Same content works in all of them.

A few things I learned keeping mine alive:

• Keep it short. One page. If it grows past that, move the detail into separate files and link to them from the main one. The agent reads the short file every time and opens the long ones when it needs them.
• Update it when you overrule the agent. Every override is a fact the file was missing. Add it the same day, or the agent will make the same call next week.
• Write decisions, not values. “We care about simplicity” does nothing. “No settings page until a customer asks for a setting” does.
• Delete what’s no longer true. A stale goal is worse than no goal, because the agent will defend it.

If you’re at the levels of agentic engineering where the agent does most of the building, this file matters more than any prompt you’ll write. The prompt covers one task. The context file covers every task after it.

Decisions are the hard part now

A founder building an AI dev tool told me recently that coding is commoditized and the decisions are the hard part. He’s right, and it’s the same taste problem it always was, with a faster clock.

Your agent can build anything now. Whether it builds what makes money depends on what you’ve told it about the business.