The Boundary Is the Product Spec

I kept running into the same AI product lesson in completely different rooms.

A sales workflow pilot that looked promising, but still needed clearer trust gates before more people used it.

A support knowledge search idea where the hard part was not retrieval quality, but permissions.

A recruiting workflow where the first question was not “can we build a RAG app?” but what candidate data the system should ever be allowed to touch.

A coding assistant evaluation where dummy data, account boundaries, and safe tool access mattered as much as the model itself.

A pricing conversation where the real risk was not just margin. It was training users to ration curiosity because usage felt unpredictable.

Different conversations. Same shape.

The hard question usually was not: can the AI do the task?

The hard question was: what is the AI allowed to know while doing it?

That is the line I keep coming back to: the boundary is the product spec.

The first spec is not the prompt

When people talk about AI products, the first draft of the conversation often jumps straight to prompts, tools, models, and UI.

Which model should we use?

Can we connect this data source?

Should this be a chatbot, agent, workflow, or internal app?

Those are all real questions. But in practice, I keep finding that the first spec should be the boundary doc.

Before the agent design, I want to know:

• What data can it read?
• Whose permissions does it inherit?
• What is it allowed to write or change?
• When should it recommend instead of act?
• Which failure modes would make the output untrustworthy?
• What evidence should it cite so a person can verify it?
• Which parts deserve frontier reasoning, and which parts should be cheap deterministic code?

That sounds less exciting than “build the agent.”

But it is usually the part that decides whether the agent can be used by more than one enthusiastic early adopter.

A pilot is not ready to scale until its failure modes have names

One pattern that showed up clearly: a pilot can look good while still not being ready to scale.

This is easy to miss because early AI workflows often produce impressive examples. A sales assistant finds useful accounts. A support assistant retrieves the right article. A document workflow drafts a useful next step. A coding tool completes the task in a sandbox.

The demo works.

But demos hide the long tail.

Before expanding a workflow, I want to know the names of the failure modes:

• wrong geography
• existing customer accidentally included
• stale account data
• contact sourced from the wrong system
• answer with no traceable citation
• permission mismatch between the viewer and the source
• private data copied into a tool that should not retain it
• model used for judgment that should have been deterministic code

Once those have names, the product conversation changes.

“Should we scale this?” becomes “which trust gates have we tested, and which ones are still unknown?”

That is a much better conversation.

Scale readiness should not be a vibe. It should be a list of known failure modes and the guardrails that make them visible.

Permissioning is user experience

Permissioning is often treated like plumbing.

It is not.

In AI products, permissioning becomes part of the user experience because the user is not just asking, “did the system answer?” They are also asking, “should this system have known that?”

That question matters inside companies.

A support knowledge assistant may need to respect article visibility, customer-specific details, private ticket history, and internal escalation notes.

A recruiting assistant may need to separate public candidate context from sensitive interview notes or internal assessments.

A sales workflow may need to avoid existing customers, suppressed accounts, private territories, or data a rep is not supposed to act on.

A coding assistant may need to know whether it is operating on dummy data, production-like data, or something with real customer implications.

The UX is not just the chat box or the workflow screen.

The UX is whether the person can trust the answer because the system was operating inside the right permission boundary.

If the user has to wonder whether the AI saw too much, too little, or the wrong thing, the product has already created cognitive load.

So the permission model is not a back-office concern. It is part of the product surface.

The action boundary matters too

There is also a difference between an AI system that can read, one that can draft, and one that can act.

Those should not be collapsed into one permission bucket.

A useful pattern is to separate the action boundary into lanes:

1. Read-only: gather context, cite sources, explain uncertainty.
2. Draft: prepare an email, note, PR comment, task, or recommendation for review.
3. Suggest action: say what should happen next, but require a human to execute.
4. Act with approval: perform the action only after explicit confirmation.
5. Act automatically: only for narrow, reversible, well-observed workflows.

A lot of internal AI work should live in the first three lanes much longer than people expect.

That is not because the models are weak.

It is because organizations need time to learn the real failure modes. The action boundary should expand only as the evidence base gets better.

This is where deterministic scripts and agents pair well.

Code should collect the source pack, enforce date boundaries, dedupe writes, parse known file formats, and keep the work idempotent.

The model should make the judgment call: what matters, what is missing, what is risky, what should a person see?

That split has become one of my favorite AI workflow patterns.

Cost is also a boundary

There is another boundary people underweight: cost.

Not just infrastructure cost. Product behavior cost.

If an AI feature makes users feel like every extra question might trigger a penalty, they will behave differently. They will ask fewer questions. They will ration curiosity. They may stop exploring exactly when the product needs usage data to understand value.

That means adoption data can become misleading.

Low usage might not mean low value. It might mean the pricing model trained people to be careful.

The same thing is true inside an AI workflow architecture.

Frontier reasoning should be treated like a premium ingredient, not the whole recipe.

Use it where it changes the outcome: judgment, synthesis, planning, prioritization, hard ambiguity.

Do not use it for every step just because it can do every step.

Routing, classification, extraction, formatting, file discovery, dedupe, and validation often belong in cheaper model lanes or deterministic code.

The cost boundary is part of the design. If it is invisible, the product will either become too expensive to use freely or too constrained to be useful.

Benchmarks are boundaries too

A product strategy conversation pushed the same lesson from a different direction.

If you want an agent-native surface to win, you eventually need to show that it is better on dimensions agents actually care about.

Not just “we have an AI roadmap.”

Better on speed.

Better on token efficiency.

Better on completion quality.

Better on source traceability.

Better on permission safety.

Better on how easy it is for another agent to use the product correctly.

A benchmark is another kind of boundary. It defines what quality means before the narrative gets too vague.

That matters because AI products are especially prone to impressive demos and fuzzy claims. Benchmarks force the team to name the axis of superiority.

If the product is agent-first, the benchmark should measure agent-relevant quality.

The package may be more important than the app

One of the more practical lessons from internal AI work is that not every problem needs a bespoke app.

A lot of teams need a packaged workflow:

• the approved data sources
• the permission assumptions
• the prompt or skill
• the connector instructions
• the examples
• the validation checklist
• the known limitations
• the escalation path

That package may live as a Claude Project, a skill, a notebook, a script, an internal template, or a lightweight app.

The important thing is not the form factor. It is that the boundary travels with the workflow.

A prompt without the boundary doc is fragile.

A connector without the permission model is dangerous.

A workflow without validation examples is hard to trust.

The package is what lets the idea spread without turning into folklore.

The operating rule

I am trying to make this a default habit:

Before I build the agent, write the boundary doc.

Not a 20-page governance memo. Just the practical product spec:

• Data boundary: what can it see?
• Permission boundary: whose access does it inherit?
• Action boundary: what can it do without approval?
• Scale boundary: what failure modes must be named first?
• Cost boundary: what deserves frontier reasoning?
• Benchmark boundary: how will we know it is better?

That is the part that makes the rest of the system useful.

The safest AI systems are not the least capable ones. They are the ones with explicit boundaries.

And the teams that get good at naming those boundaries will move faster, not slower, because they will know which parts of the workflow are safe to automate, which parts need review, and which parts are not ready yet.

The boundary is not bureaucracy.

The boundary is a product spec.