Your Claude Prototype Works for You. Here's How to Make It Enterprise-Ready.

A couple of years ago, if you wanted an internal AI tool, you hired engineers. Today, a head of operations, a founder, or a CEO can connect Claude to company systems and have something up and running within days. Gartner expects 40% of enterprise applications to include task-specific AI agents by the end of 2026, up from less than 5% in 2025.

Our engineers see these prototypes regularly, usually right after they stop moving forward. What's striking is how similar the stories are. Different companies, different systems, same walls, in roughly the same order.

One of the clearest examples came from S&B Filters, a U.S. manufacturer of automotive air filters with 700+ employees. Their CEO, Berry Carter, connected Claude to NetSuite through the Model Context Protocol and built an assistant to answer the question his team hears all day: "Where is my order?"

It worked and proved the use case. It also took four to six minutes per answer and ran on a prompt roughly 40 pages long.

Our team didn't patch that prototype. We rebuilt it on a production architecture. But almost everything the prototype had taught Berry's team carried over, and that's why the rebuild took weeks, not months. Along the way, the assistant ran into nearly every wall below.

• 

Wall 1: The regression spiral

What it looks like: You fix one thing, and something else breaks. You ask Claude for a small change, and two behaviors that used to work are now quietly wrong.

How it showed up at S&B: The 40-page prompt held everything: tone, rules, exceptions, policies. That's why it worked early on. But every request carried all 40 pages, and changing one rule didn't guarantee the other 39 would still behave the same way. A prompt that size isn't something you can safely refactor. It's a sign the architecture needs to change.

What our engineers do:

• Keep what the prompt learned, not the prompt itself. Those 40 pages are the best requirements document you'll ever get: which questions matter, which exceptions come up, and how the business wants to answer. Our engineers mine that before writing any code. Then they split the work: the assistant decides what's being asked and calls the right tool (order lookup, inventory check, knowledge search), each with its own focused instructions.

• Build a test set from real questions before making any changes. Start with real conversations and tickets, then expand them into 100+ test cases with known good answers. Every change gets checked against that set, so you find out a change broke something before your users do.

Wall 2: Integrations that fail silently

What it looks like: The connection works, mostly. Some records come back partial, some answers are confidently wrong, and you can't tell whether the problem is the integration, the model, or the prompt.

How it showed up at S&B: Three different ways.

1. Messy inputs. Order numbers came in through Shopify, phone, and email, each in its own format. People also typed part numbers with prefixes the system didn't recognize.
2. The wrong source of truth. NetSuite was right for order data but wrong for part numbers. It holds tens of thousands of sub-components, many of which customers can't buy, so lookups sometimes matched parts that weren't actually products. Shopify had a clean list of about 2,000 finished goods.
3. Facts answered from documents. Vehicle fitment questions ("What filter fits a 2013 F-150?") were being answered from a knowledge base text, and that's where the assistant hallucinated.

What our engineers do:

• Normalize inputs before they reach your data. Validate across formats, then fall back across identifiers: sales order, then PO number, then customer reference.
• Pick the source of truth per question, not per system. Don't ask "Which system has this data?" Ask "Which system has the version of this data that the customer means?" At S&B, part-number lookups moved to Shopify SKUs.
• Use structured data for facts and documents for explanations. If an answer has a correct value in a database, the model should look it up, not infer it. S&B's assistant now searches the structured fitment data directly and asks for missing details, like engine type, instead of guessing.

Wall 3: It works for you, not for everyone else

What it looks like: The demo is great. Then a colleague says, "It doesn't work for me," and when you try it, it works perfectly.

How it showed up at S&B: The prototype was built for one user, the person who made it. He typed clean inputs and didn't mind waiting four minutes. The business needed two very different users: support agents with a customer on the phone, and customers on the website who expect an answer in seconds.

What our engineers do:

• Test on your messiest real inputs, not your own. Pull real tickets, real chat logs, real typos.
• Set a speed target before you build. Ask "How fast does this need to be for the person waiting?" That question influences architectural decisions more than "Is the answer right?" does. At S&B, it led to direct data retrieval from the ERP and streamed responses.
• Design for each audience separately, on one core. S&B ended up with one architecture and two front doors: an internal assistant for agents and a customer-facing one on the website.

Wall 4: Something is wrong, and you can't see what

What it looks like: A number doesn't match, an answer seems off, things feel slower. Every investigation is guesswork because nothing records what the system actually did.

How it showed up at S&B: Once the assistant was live, the questions shifted. Which conversations went wrong? What were customers asking that it couldn't answer? A knowledge-gaps dashboard surfaced 208 gaps, which were more than anyone could act on.

What our engineers do:

• Log every conversation in a form that a person can review. S&B's team reviews real chats, not just aggregate numbers.
• Turn raw signals into a short list. For those 208 gaps, the team agreed to export the data and work from the top 5–10 that actually come up. A list nobody acts on isn't visibility.
• Design the handoff to humans. During support hours, a frustrated user reaches a live agent, who receives an AI-written summary and the full chat history, so the customer never has to repeat themselves. Outside of hours, the assistant creates a ticket. Knowing exactly what happens when the AI can't help is part of knowing what the system is doing.

Wall 5: The freeze

What it looks like: The last few changes were so painful that you've stopped making them. The prototype works, mostly, and you're afraid to touch it.

How it showed up at S&B: Policies and product content were embedded in the prompt, so every content update required editing the prompt. That's exactly the kind of change that sets off Wall 1.

What our engineers do:

• Move knowledge out of the code. S&B's product content now lives in a OneDrive-connected knowledge layer that the team already maintains. Updates go live without a redeploy, and visibility rules keep internal information internal.

• Roll out new capabilities in small, reversible steps. S&B's next step is automating email tickets, and the plan is deliberately cautious: order status only at first, weekends first, a clear note that the reply is AI-generated, and the option to reply "no" to reach a human. Small steps make change feel safe again.

  

Where it ended up

The first production piece, the internal order-status assistant for support agents, was live within about four weeks, with first responses 98% faster, from minutes to seconds. The customer-facing website assistant and the knowledge layer follow in the next phase.

In Q2 alone, about 5,600 website visitors used the assistant to look something up, and 83% of their requests were resolved without an agent stepping in. Order status was still the top use case.

As Berry Carter, CEO of S&B Filters, put it:

The initial solution I built was slower than I needed it to be, simply because I wrote it… We now get all that information in 15 seconds for our techs, which is just phenomenal.

The full story is in the S&B Filters case study.

The order in which our engineers work

Getting past the walls isn't about fixing everything at once. On most prototype projects, the work follows the same sequence:

1. Mine the prototype before touching it. Collect the prompts, real conversations, and edge cases. Decide what carries over (the use case, the logic, the knowledge) and what gets rebuilt (usually the architecture).
2. Build the test set from real questions before changing anything.
3. Fix the data layer: sources of truth, input normalization, structured lookups.
4. Rebuild the architecture around that logic: tools instead of one giant prompt, latency targets, and knowledge moved out of the code.
5. Add visibility and human handoff, so you can see what's happening and catch what the AI can't handle.
6. Roll out in stages: one use case, one channel, one audience at a time.

That sequence is why "weeks, not months" is realistic. You're rebuilding the engine, not rediscovering the product.

Before you take your prototype further

1. Can you name the questions your prototype answers well, with real examples?
2. Have you tested it on your messiest real inputs?
3. For each type of question, do you know which system is the source of truth?
4. Are factual answers coming from structured data, or from documents?
5. Do you have a speed target for the person waiting for the answer?
6. When the AI can't help, who gets the conversation, and with what context?
7. Can someone update the content without touching the code?

If most of your answers are "no," your prototype isn't failing. It has done its job: it proved the idea. Now it needs a foundation.

For more on how each wall feels from the builder's perspective, see our deeper look at the five walls. For the product-team angle, this HackerNoon piece argues that prototypes fail when they lack context about the real system.