Is It an AI Agent or a ChatGPT Wrapper? One Test, and What It Takes to Build on the Right Side of the Line

I sat down with Sam Dey on the DataScienceWithSam podcast to talk about what it actually takes to build on the right side of that line. The episode, "Building AI Agents That Actually Work in Production," is on Apple Podcasts, Spotify and YouTube. This is the written version of the argument.

The wrapper test

A wrapper is a product whose whole value is the model underneath. The prompt is the product. When the model gets a native feature that does the same thing, the wrapper has nothing left.

What survives that test is everything around the model: the connection to a business's own data, the permissions that decide what the agent can touch, the integrations that let it act inside real systems, the review steps where a person decides, and the memory that lets it pick up where it left off. None of that ships from a model provider, because none of it is generic. It is specific to one business.

That is why we build full-custom workflows for small and midsize businesses rather than a product everyone configures. The generic layer is where the wrappers live. The specific layer is where the value is, and privacy is the real differentiator inside it.

Discovery first, before any code

We charge for discovery and we do it before we write a line. That surprises people who are used to free pilots. The reason is simple: the expensive mistakes in AI projects happen at the pick, not at the build. Wrong problem, wrong priority, technology chosen before anyone asked what hurt.

Discovery maps the workflow with the people who do it, names the systems and the data, and sets the baseline that the build is measured against. If the honest answer at the end is "fix the process first," we say so. The first-workflow guide is the public version of the scoring we use.

Real data from day one, never a clean demo environment

A demo environment with tidy sample data proves nothing. Real businesses have two customer records for the same person, invoices with the PO number in the notes field, and a calendar with rules nobody wrote down. We build against the real data from the first week, with customer details handled under the client's own access controls, because that is the only way to find out what the agent will actually meet in production.

Private GPT: lives in your environment, nothing sent for training

The question every security-conscious buyer asks is where the data goes. Our Private GPT deployments run inside the client's environment, under their identity provider, with their documents indexed under the permissions people already have. Requests go only to a model provider the client approves under enterprise terms, or to a model running inside their own boundary. Nothing is sent to train anyone's model. The own-cloud deployment guide has the architecture, and the K3 Technology case study is a deployed example.

A real client story: 44 years of PDFs

The Jury Verdict Reporter of Colorado has published verdict and settlement data for Colorado attorneys since 1983. Decades of it lived in PDFs that researchers searched by hand. We rebuilt the research operation around an AI-searchable archive, so a question like "construction-site injury verdicts in Colorado" returns the matching cases with citations in minutes instead of hours, and built the subscriber and billing software around it. JVRC owns the system. The case study has the details.

That is not a wrapper. If a model provider ships a better retrieval feature next quarter, the archive, the permissions, the citations and the subscriber system are all still JVRC's, and we swap the model underneath.

The baby-steps rule for agent permissions

One task. One sandbox. Expand only after validation.

Every agent we deploy starts with the narrowest useful permission: read this mailbox, draft but do not send, prepare the posting and let a person click it. It runs that way until the logs show it behaving correctly on real volume. Then the next permission is added, one at a time, with the same review. Autonomy is earned from evidence, not granted at launch. It is the single practice that has kept our deployments out of trouble.

The prediction

Sam asked where this goes. My answer: the boring, narrow, plugged-in stuff is what will definitely win. Not the impressive general assistant. The agent that checks 500 invoices a month, answers the 7pm call, or finds the verdict in the archive. Those are the ones that survive the renewal, and they are the ones that survive the wrapper test.

Frequently asked questions

How can I tell if an AI product is just a ChatGPT wrapper?

Ask whether the product would still exist if the model provider shipped the same feature natively next quarter. If the value is the prompt and the UI, it is a wrapper. If the value is the connection to your data, permissions, integrations, review steps and memory, it is an agent.

Why does HummingAgent charge for discovery before building?

Because the costly mistakes happen at choosing the problem, not at building. Paid discovery maps the workflow with the people who do it, sets the baseline, and sometimes concludes the first project is a process fix, which is cheaper to learn before a build.

What is the baby-steps rule for AI agent permissions?

One task, one sandbox, expand only after validation. Start with the narrowest useful permission, run on real volume until the logs show correct behavior, then add the next permission with the same review.

Where does the data go in a Private GPT deployment?

It stays in the client's environment, under their identity provider and permissions. Model requests go only to a provider the client approves under enterprise terms, or to a model inside their own boundary. Nothing is used to train anyone's model.