Optional Intelligence: Designing AI Features That Can Be Switched Off

Executive Summary

Optional intelligence is a design standard for AI features: the product works completely without the model, so the AI degrades gracefully, is bounded in cost, sees only the data it needs, and stays reviewable by a human. When the model is absent, the user never notices. When it is present, the product is better.

Teams adding AI to products tend to ask what the model can do. A more useful question is what happens when it doesn’t.

Models are slow on some days, wrong on others, expensive when abused, and occasionally unavailable. A product that depends on them for its core job inherits all of those properties. A product that treats them as an optional layer inherits none.

This paper describes four properties that make an AI feature safe to ship, plus a short drill for testing them. None of the four depends on a particular model or vendor.

Why do AI features become a dependency trap?

The pattern is familiar. A team prototypes an AI-driven flow, discovers that it looks great in a demo, and wires it into the main path. A few weeks later the first incidents arrive: a timeout that blocks checkout, a rate limit that fails every user at once, a surprising bill, a response that was fluent and wrong.

None of these are model failures in the abstract. They are architecture failures: the product was designed as though the model were infrastructure, with the reliability people expect from a database, when it behaves more like a talented contractor who is sometimes late, sometimes confident in the wrong direction, and always billed by the hour.

What does optional intelligence mean in practice?

It means four properties, each testable on its own.

Property	The question it answers	What it looks like in code	What goes wrong without it
Degrades gracefully	What happens when the model fails?	Baseline flow first; every error path returns to it silently	A timeout blocks the core job
Bounded	What is the most this can cost?	Per-visitor and global daily caps, checked before the call, failing closed	A surprise bill or an abused endpoint
Sees only what it needs	What did we send, and why?	An explicit allowlist of fields; untrusted text in a delimited block	Leaked personal data; instructions smuggled in through user text
Reviewable	Who approves the output?	Generated content shown in an editable form before it takes effect	Fluent, wrong content acted on automatically

The rest of this paper takes them one at a time.

Property one: degrades gracefully

The test is blunt. Delete the API key and use the product. If the main flow still completes, the feature is optional. If it breaks, it is a dependency, and should be treated with the seriousness that word implies.

Graceful degradation is easiest when it is designed first. Build the baseline, the plain version that works without intelligence, then add the AI path as an enhancement that can be removed without touching the baseline. Every failure mode (missing key, rate limit, timeout, malformed output, empty response) resolves to the same place: the baseline, silently, with no error screen for the user to interpret.

Our own project interview works this way. It is a nine-step scripted conversation, and that script is the product. An optional server function may add up to two follow-up questions and draft a brief, and if it does nothing at all, the visitor never learns it was supposed to.

Property two: bounded

Optional is not the same as free. An endpoint that calls a model is a spending mechanism exposed to the internet, and it needs limits that operate before the money is spent, not after the invoice arrives.

Practical bounds are unglamorous: a cap per visitor per day, a global daily ceiling, a request size limit, a short timeout, and a counter that is checked before the call, not after. The counter should also fail closed. If the system cannot confirm that budget remains, the AI feature switches itself off and the baseline carries on. A broken meter should never become a blank check.

Bounds also include scope. A model asked to do one narrow job is easier to constrain and test than one asked to be generally helpful. “Write one follow-up question or return nothing” is a job that can be validated mechanically.

Property three: sees only what it needs

Every piece of data sent to a model is a decision, and the safest default is to send less. Before an AI feature ships, list what it receives and ask of each field: does the result get better because the model saw this?

For an intake interview, the project description improves the follow-up question. The visitor’s phone number and email do not. In our implementation contact details are never sent to the model. Data that is never sent cannot be retained, leaked, or reflected back in an output, and the privacy statement writes itself.

The second half of this property is treating the text that does reach the model as untrusted. Anything a visitor types is potentially an instruction aimed at the model, so it belongs in a clearly delimited block, framed as data, with a system prompt that says so and an output format the server validates before anyone sees it.

Property four: reviewable

A model’s output should be a proposal until a person accepts it, wherever the stakes are more than trivial. In practice that means showing generated content back to the user in an editable form before it is sent, saved, or acted on.

This isn’t just a safety measure. It improves the product. People correct what is wrong, and correcting is a form of thinking: the visitor reading an AI-drafted project brief notices the detail the model missed, adds it, and ends with a better brief than either could have produced alone. The model supplies a first draft, the human supplies judgment, and the interface makes the handoff explicit.

For actions with consequences beyond text, such as sending money, messaging customers, or changing records, the same principle extends: the more irreversible the action, the more explicit the human confirmation. Our earlier note on agents that fail loudly covers that side in more depth, and the two ideas reinforce each other.

How should an optional AI request flow through a system?

The four properties map onto a single request path. Each gate can end the request without the visitor noticing, and every exit leads to the baseline.

  Visitor action (e.g. finishes a step)
        |
        v
  [Gate 1] Is the feature enabled and the key present?
        | no -----------------------------> baseline
        v
  [Gate 2] Per-visitor cap and global daily cap OK?
        |   (counter unreadable counts as "no")
        | no -----------------------------> baseline
        v
  [Gate 3] Build request from allowlisted fields only
        |   (no contact details; user text in a delimited block)
        v
  Model call with short timeout
        | error / slow / empty -----------> baseline
        v
  [Gate 4] Server validates output shape and content
        | invalid ------------------------> baseline
        v
  Show to the visitor as an editable proposal
        |
        v
  Visitor accepts or rewrites -> normal pipeline

Notice that nothing on the left edge of this diagram can produce an error screen. The only exits are the baseline or an editable proposal.

The Kill-Switch Drill

Reading about graceful failure is easy. Proving it takes four short tests, which we run before any AI feature ships.

1. Delete the key. Remove the API credential and complete the main flow. It should work unchanged.
2. Exhaust the budget. Set the cap to zero, or make the counter unreadable. The AI path should switch itself off, not fail open.
3. Return garbage. Make the model return empty text, malformed structure, and an off-topic answer. The server should reject each and fall back.
4. Make it slow. Delay the response past the timeout. The user should continue without waiting on it.

If every drill ends with the user finishing the job and seeing no error, the feature is optional. If any one does not, fix that before shipping anything else.

A worked example (illustrative)

Take a hypothetical accounting practice that wants an AI feature on its client portal: summarize a client’s uploaded questions into a short note for the accountant. This is an invented example.

Run the four properties against it.

• Degrades gracefully. If the summary fails, the accountant still sees the client’s original questions, in full. The summary is a convenience on top of data the portal already shows.
• Bounded. One summary per upload, a per-client daily cap and a global daily cap, checked before the call. If the counter is unreadable, no summary is generated.
• Sees only what it needs. The questions go in. The client’s tax identifiers, account details and contact information do not, because the summary is not better for having them.
• Reviewable. The accountant sees the summary labeled as machine-written, and can edit or discard it. Nothing is sent to the client automatically.

Now the contrast case. Suppose the same practice instead let the model decide which documents a client still owes and message them automatically. Every property is stressed at once: failure blocks real work, the cost scales with client count, the model would need sensitive data, and an error is sent to a customer with no human in the way. The first design is optional intelligence. The second is a dependency with a customer-facing blast radius, and it should wait until each of those risks has an owner.

What does optional intelligence cost?

It is slightly more work up front. You build the baseline and the enhancement, you write tests for both paths, and you accept that the AI path will be one that some visitors never see. You also give up the satisfaction of a product that is visibly AI-native at every step.

The stack stays small while you do it. Our site is Astro static pages on Cloudflare Pages with a few Functions, a D1 database and R2 storage, and the AI feature is a single capped function among those few. A full build of well over a hundred pages takes about ten seconds, so adding or tightening a gate is a same-day change, not a project.

What you get in exchange is a feature you can ship on a Friday, turn off from a dashboard in a minute, and describe plainly to a customer who asks what happens to their data. For most businesses that is a better trade than a more impressive demo.

A checklist

Before shipping an AI feature, confirm each of these in writing.

1. The product’s core flow works with the model switched off.
2. Cost is capped per user and in total, and the cap fails closed.
3. The model receives only the fields that improve its output.
4. Visitor text is treated as untrusted data, and output is validated.
5. A person can review and edit what the model produced before it takes effect.
6. There is one clear way to turn the feature off.
7. The Kill-Switch Drill passes on all four tests.

Conclusion

The industry’s instinct is to make AI central. A better habit is to make it removable. The most capable systems we have built treat intelligence the way good teams treat a gifted but unpredictable colleague: use them where they help, review what they produce, and make sure the business keeps running when they are out of the office.

Related reading

• Agents That Fail Loudly
• Rate-limiting an AI endpoint with a single D1 table
• Treating visitor text as untrusted when it reaches a model

Frequently asked questions

What does it mean to design an AI feature that can be switched off?

It means the product's core job completes with the model removed. You build the plain baseline first, then add the AI path as an enhancement that touches nothing in the baseline. Every failure, including a missing key, rate limit, timeout or malformed output, resolves silently to the baseline, with no error screen for the user.

How do you stop an AI feature from becoming a single point of failure?

Keep it off the critical path. Put it in a separate server function, give it a short timeout, validate its output mechanically, and return nothing on any failure so the baseline flow continues. Then test the failure paths first. If deleting the API key breaks the product, the feature is a dependency, not an option.

How do you cap AI costs on a public endpoint?

Treat the endpoint as a spending mechanism exposed to the internet. Cap calls per visitor and globally per day, limit request size, set a short timeout, and check the counter before the call rather than after. Make the counter fail closed, so if budget cannot be confirmed, the AI feature switches itself off.

What data should you send to an AI model?

Only fields that make the result better. For an intake interview, the project description improves a follow-up question while the visitor's email and phone number do not, so they stay out. Data never sent cannot be retained, leaked or echoed back, and it makes the privacy statement short and true.

Should a person review AI output before it takes effect?

Wherever the stakes are more than trivial, yes. Show generated content in an editable form before it is sent, saved or acted on. People correct errors and add what the model missed, which improves the result. The more irreversible the action, such as payments or customer messages, the more explicit the human confirmation should be.

How do you test whether an AI feature is truly optional?

Run four drills: delete the API key, exhaust the budget, return garbage from the model, and make it slow. In each case the user should finish the main flow without seeing an error. If any drill produces a broken screen or a blocked checkout, the feature is a dependency and needs redesign.

More from Research

• No, Your Website Isn't Finished
• Own the First Conversation
• The Shortlist Is Back: Being Named When AI Answers for Your Customers