An AI agent isn't a product. The job to be done is.

You shipped an AI agent that can answer anything about your domain. The architecture is elegant, the demo lands, leadership is impressed. Then you open the usage dashboard a month later and almost nobody is touching it. I've been here, and the reason has very little to do with the model.

We'd built an AI platform for supplier intelligence and benchmarking around one bet: a powerful, open-ended agent. Ask it anything, and a scalable harness underneath would resolve the right values, reason over them, and write its own queries from scratch. I was convinced flexibility was the gift we were handing users. Internally, it barely got used. This note is about why, and the pattern we replaced it with, because the failure mode is everywhere right now.

Why the open-ended agent doesn't get used

The problem is the blank canvas, and it shows up as three compounding things:

Users don't know what to ask. Someone lands on a chat box with infinite surface area and no idea what's possible. "Can it do X? Will it understand how we name Y?" The cost of figuring out the question is higher than the value of the answer, so they leave. A blank prompt is a cold start you've asked the user to solve, and most won't.

People come for specific, recurring answers. Watch what users actually want from an enterprise tool and it's rarely open-ended. It's the same handful of questions asked again and again: this supplier's spend, this category's benchmark, this peer set. They came for a known answer and you made them compose a query to get it.

No quick actions means no on-ramp. The things people did most often were buried inside the agent instead of one click away. We'd optimized for the rare exploratory question and taxed the common one.

The pattern: codify the jobs, then let the agent connect them

We inverted the build. Instead of one agent that can solve anything, we solved the specific things, and then let the agent connect them.

Codify the recurring jobs into direct surfaces. We pulled supplier intelligence and benchmarking into one product and shipped clean dashboard cuts for the handful of questions people actually came for, the most sought-after information in the firm. The answer now sits on the page, not behind a prompt.

Reuse the harness; don't throw it away. The scalable backend we'd over-built wasn't wasted. It now powers those cuts, exposed as typed APIs we built alongside the rest of the engineering team. Same infrastructure, opposite product.

Let the agent become the connective tissue. Here is the part I didn't expect: codifying the jobs made the agent better, not redundant. Because every cut was now an API with its own UX, the agent stopped writing queries from scratch and started calling building blocks that provably work. Its role sharpened, too. The obvious answers live on the page, so the agent became how people find the non-obvious ones: the slices codified into other modules they weren't even looking in.

What changed

• The product got used, because the common jobs are one click and nobody has to solve a blank canvas.
• The agent got used too, for the right reason: about 40% of users reach for it, mostly to find non-obvious information that lives in a different module than the one they're in.
• The agent got more reliable, because it now composes validated, pre-built APIs instead of generating and testing fresh queries as it tries and fails its way through a user's open-ended problem.
• Every new cut we ship extends both surfaces at once: the product, and the agent that routes across it.

When an open-ended agent IS the right call

Genuinely exploratory work where the questions aren't knowable in advance. Expert users who can phrase precise queries and read the output critically. A domain with no stable set of recurring jobs to codify. If your usage data shows a long tail of one-off questions rather than a fat head of repeated ones, the canvas really is the product. For most enterprise tools it's the opposite: a few jobs dominate, and those deserve to be solved directly.

Adopting it: a short checklist

1. Pull your usage logs, or just ask your power users, and rank questions by frequency. The fat head is your roadmap.
2. Ship the top few as direct, one-click surfaces, not prompts.
3. Wrap each one as a typed API, so the product and the agent share the same building blocks.
4. Point the agent at those APIs and let it do what it's genuinely good at: routing people to the right slice across modules.
5. Measure the agent on whether it surfaces the non-obvious, not on whether it can answer everything.

The one-line version

An agent isn't a product; the job it does is. Solve the known, high-value jobs directly, package them simply, and let AI be the connective tissue across them, not the front door.