Key takeaways
  • Agentic AI has given your product a second user: an autonomous agent that plans and acts, not a human who clicks.
  • That user breaks your assumptions: it ignores your UI, acts at machine speed, and repeats a mistake thousands of times before anyone notices.
  • The scarce new skill is the "constitution": defining the non-negotiable limits an agent can never cross — designing what your product must never do.
  • In regulated products the bright lines come first. An agent that can move money, approve credit or run KYC needs its guardrails defined before its features.

While everyone spent the last year arguing about whether AI would replace the product manager, something quieter happened: your product got a second user, and it isn't a person. Agentic AI (systems that don't just answer, but plan, decide and carry out multi-step work) has moved from demo to production. And more and more of the traffic hitting your product isn't a human clicking a button. It's an agent, acting on someone's behalf, at a speed and scale no human user ever managed.

This is the shift the roadmap debates keep missing. It isn't that AI helps you build faster. It's that AI has become a user of the thing you built — and it behaves nothing like the one you designed for.

Meet your other user.

There are two flavours of it, and you probably have both. The agent inside your product: the thing you shipped to "add AI", now autonomously looking up accounts, moving data, taking actions. And the agent outside it: your customer's own assistant, calling your product through an API or an integration to get a job done without a human ever opening your app. Either way, a large and growing share of what your product does is now initiated by software that reasons and acts on its own.

It breaks every assumption you designed for.

Every product decision you've ever made assumed a human on the other end — one who reads, hesitates, notices when something feels wrong, and makes one mistake at a time. An agent does none of that.

Diagram · Two users, two design problems
The human user versus the agent user A comparison table across four rows. The human user reads the UI and learns the flow; the agent user reads your API and docs and ignores the UI. The human moves at human pace and hesitates; the agent acts in milliseconds and doesn't hesitate. The human makes a mistake once; the agent repeats the mistake thousands of times. The human is bounded by attention and effort; the agent is bounded only by the guardrails you set. THE HUMAN USER THE AGENT USER LEARNS Reads the UI, learns the flow Reads your API, ignores the UI SPEED Human pace, hesitates Milliseconds, no hesitation ERRORS Makes a mistake once Repeats it ten thousand times LIMITS Bounded by attention Bounded only by your guardrails
A human user is self-limiting — they get tired, they double-check, they stop. An agent isn't. The only thing standing between it and a very fast, very repeated mistake is the limits you designed in on purpose.

The new job: writing the constitution.

For twenty years the central product question was "what should we build?" For agentic products, the more important question is its mirror image: what must our product never be allowed to do? That's not a footnote in the spec — it's the spec. With a human user you design the happy path and trust the person to stay roughly on it. With an agent, there is no trust; there is only what you have and haven't permitted. The guardrails (the hard limits, the things the agent physically cannot do no matter how confidently it decides it should) stop being a safety afterthought and become the product itself. Call it the constitution: the small set of non-negotiable rules the system is built around, not bolted onto.

In fintech, the bright lines come first.

Nowhere is this starker than where the agent can touch money. An agent that can initiate a payment, approve a limit, move a balance or run a compliance check is not a feature — it's a loaded instrument. The demo is intoxicating: it handles the whole workflow, end to end, in seconds. Production is the part nobody films: the same agent, running thousands of times a day, one confidently-wrong decision away from a very bad morning. The teams that build agentic products well in regulated markets don't start with what the agent can do. They start with what it must never do: never move funds above a threshold without a human, never act outside an explicit allow-list, never take an irreversible step it can't explain. Define those first, and everything else is safe to move fast on. Skip them, and you've shipped a fast, tireless way to make the same mistake at scale.

With a human user you design the happy path. With an agent, you design the lines it can never cross.

Why this matters now.

Agentic features are being shipped this year at a speed that outruns the thinking behind them. The pattern is familiar and worrying: the pilot dazzles, the rollout stalls, and when it fails it usually isn't the model or the interface. It's that nobody defined the limits, the permissions, or what happens when the agent is confidently wrong. The teams that win the agentic era won't be the ones whose agent can do the most. They'll be the ones who were clearest, earliest, about what it must never do — because in a world where your product acts on its own, restraint isn't the brake on the product. It is the product.

How we use this at Product Pieces.

Most teams shipping agentic features have spent all their energy on what the agent can do, and almost none on the constitution — the permissions, the limits, the failure modes when it's wrong. That's usually the missing piece, and it's exactly what the free Diagnostic is built to surface: whether what your product function is short of is the senior judgment to define those bright lines before the thing goes live. In an agentic product, the guardrails are the design. Getting them right, before real money flows through them, is the piece we plug in.