Last updated: September 12, 2026
A custom AI assistant for business is a chat tool that answers questions from your own documents and records, by searching them first and handing the relevant passages to a language model along with the question. Training a model is rarely any part of the job. What these things need is permissions, one narrow question, and an owner.
Last October I was at one of those dirt fields somebody converts into a money machine every autumn. My two kids were rolling around in a corn pit. I paid about twelve dollars for apple cider donuts, and I would pay it again. Worth it.
And then my brain did its thing. It always does this. How would you elevate this experience with some cloud-based technology and AI?
Nothing. There was no improvement available. Their minds were absolutely popped by a pit of corn kernels and no software was going to beat that.
So I built CORN-GPT.
It is a custom model that answers questions about ERP, ecommerce, integrations, business process, and business tech stacks entirely through the lens of corn and corn agriculture. It is exactly as useful as that sounds. Which is to say, barely. People still send me feedback on it, which says more about my network than about the bot.
The useful bit is what came next. Making it was trivial. Genuinely trivial. Anyone with a paid ChatGPT account can stand one up before lunch, and plenty of your employees already have. You upload a few files, write some instructions, name the thing, publish. That is it.
If building an assistant is that easy, and it is, then the assistant was never the project.
My corn bot has no permissions to respect. Nobody loses money when it is wrong. Nobody on my team has to trust it on a Tuesday afternoon with a customer on hold and a shipment sitting in a dock door. The one you are thinking about building has all three of those problems on day one, and not one of them gets solved by picking a smarter model. Better models do not help.
I have written before about where to actually start with practical AI in business operations, and this is that same argument aimed at one specific tool. Start narrow. Pick something boring. What is different about an assistant is that it fails in ways an automation does not, and most of those failures are about who is allowed to read what.
I build these at Foretopia. KORE1, whose blog you are reading, staffs the people who end up running them, and their IT staffing desk starts seeing that role open about six months after launch. Park that. I come back to it at the end.
What You Are Actually Building, in Four Boxes
Strip the branding off and an internal AI assistant is four parts. A defined set of sources it is allowed to read. A search step that pulls the handful of passages relevant to a question. A language model that turns those passages into an answer. And a front door with permissions on it.
That is the whole machine. Box three is the one every demo shows you. Every single one.
Box two is where the work is. Your documents get chopped into chunks, each chunk gets converted into a vector, and the vectors go into an index. Somebody asks a question, the question becomes a vector too, and the system grabs the chunks sitting nearest to it. Those chunks go to the model with an instruction that amounts to “answer using only this.” The industry calls the pattern retrieval augmented generation, which Lewis and colleagues named in a 2020 paper and every vendor has been renaming ever since.
You do not have to care about vectors. You do have to care that answer quality is mostly decided before the model ever sees the question, because if the search step hands over the wrong four paragraphs, a better model just writes a more convincing wrong answer. Faster, too.
Box four gets skipped in the room and discovered in production. Two sections down.
Retrieval or Fine-Tuning, and Why You Probably Want the First One
This is the fork where mid-market companies get talked into the expensive version, so let me be blunt about the difference.
Fine-tuning changes how the model writes. Retrieval changes what the model can see. Those are not competing options, they are different jobs, and roughly nine out of ten people who tell me they want to “train AI on our company data” are describing retrieval. They just do not know it.
| Question | Retrieval (RAG) | Fine-tuning |
|---|---|---|
| What does it change? | What the model can see | How the model writes and formats |
| Best for | Facts that change, policies, contracts, records | House style, rigid output formats, a niche code dialect |
| Cost of an update | Re-index the changed file, minutes | Rebuild the training set and retrain, weeks |
| Can it cite a source? | Yes, down to the document and page | No |
| When it is wrong, can you tell why? | Usually, you can read what it retrieved | Rarely, the mistake is baked in |
| Right for a first project? | Almost always | Almost never |
A policy that changed in March is a retrieval problem. Swap the file, re-index, done in the time it takes to reheat coffee. Do that with fine-tuning and you are rebuilding a training set to correct one paragraph. Nobody does that twice.
Fine-tuning does earn its keep. We use it on our own development work, where nine years of accumulated NetSuite codebase teaches a model our conventions in a way no prompt ever will, and I wrote up how that actually went in AI-augmented development. Notice the shape of that use case though. Stable, enormous, stylistic, and owned by people who can read the output critically. A policy handbook is none of those things.
Ask the vendor which one they are selling you. Then wait. If the answer takes more than a sentence, that is your answer.
It Reads Whatever You Let It Read
Here is the failure I have watched land hardest, and it is never in the pitch deck.
Somebody points the indexer at the company file share. All of it. Scoping is tedious and the whole drive is right there. Two weeks later a coordinator in customer service asks a perfectly innocent question about headcount on a project, and the answer quotes a compensation spreadsheet from a folder she has never been able to open in eight years of working there.
The model did not break in. It was handed the chunk.
Language models have no permission system. Not one of them. Your file share has one, your ERP has one, your HR platform definitely has one, and the moment you copy content out of those systems into a search index, you have left every one of those permission systems behind unless you deliberately rebuilt them inside the index. Most first builds do not, because the fastest way to get an index working is one service account that can read everything, and that account is now effectively every user in the building. Think about that.
NIST names this class of problem directly in its Generative AI Profile, alongside a term worth stealing for your next steering meeting. Confabulation. They define it as the production of confidently stated but erroneous or false content. Two different risks, one interface, and users cannot tell them apart because both arrive in the same calm paragraph.
There are two honest fixes. Carry permissions into the index so every retrieval is filtered by who is asking, which is real engineering and costs real money. Or scope version one to a document set everyone with access to the assistant could already open on their own, which costs nothing and is what I recommend to almost everybody.
Pick the second one. Ship it. Earn the first one later.
None of this requires a governance committee, by the way. It requires a page. I laid out what that page needs to say in AI governance for the mid-market, and the only line an assistant adds is a written answer to one question. What is it allowed to read, and who signed off on that list. Two lines.
The Number That Should Give You Pause About Building
I am going to argue against my own headline for a minute.
In July 2025 a team out of MIT’s Project NANDA published The GenAI Divide: State of AI in Business 2025, and the headline finding got quoted everywhere. Ninety-five percent of organizations were getting zero return on generative AI. The finding nobody quoted is the one that should sit on your desk. In their sample, external partnerships with customized tools reached deployment about 67 percent of the time. Internal builds reached deployment about 33 percent of the time. Internal builds failed roughly twice as often. Same models, same tools.
Read that report the way its authors ask you to. It covers 52 structured interviews, 153 survey responses and a review of more than 300 disclosed AI initiatives, the outcomes are self-reported, and page two carries a disclaimer noting the views are the authors’ own. It circulates as a PDF rather than through a journal. Read it anyway. I still think the direction is right, because it matches what I see in the field, and because the mechanism is obvious once you have run a few of these.
Internal builds fail more often because internal builds have no deadline, no contract, and nobody whose bonus depends on it working in November. There is your mechanism.
Now the other number from that same report, which cuts the opposite way. Forty percent of companies had bought an official LLM subscription. Employees at more than ninety percent of surveyed companies reported using personal AI tools for work anyway. Ninety.
Sit with that gap for a second. Your pricing sheets, your customer emails, your draft contracts, your board deck notes, all of it is already being pasted into somebody’s personal account on a laptop you do not manage and cannot audit. The question was never whether your company data was going to meet a language model. Happened a while back, without a meeting. The only open question left is whether it happens somewhere you can see.
McKinsey’s 2025 State of AI survey found 88 percent of respondents reporting regular AI use in at least one business function, and no more than 10 percent scaling agents in any single function. Everybody is using it. Almost nobody has it in production anywhere specific. That distance is the entire opportunity. It is also the entire risk.
So here is where I land, and it is narrower than the title of this post. Do not build what you can buy. If Microsoft 365 Copilot, or a vendor tool already wired into your help desk, answers the question you have, buy it and get on with your life. Build the one narrow thing nobody sells, which is almost always the assistant that has to read your ERP, your product data, or a contract set nobody outside the building has ever seen. I sorted the buy pile from the build pile in more detail in AI in ERP, what is real and what is hype.
Scope It to One Question, Asked Weekly
Every internal assistant I have seen work started life answering one question somebody was already sick of answering. Every one I have seen die started as a company-wide knowledge platform.
Five steps to pick yours.
- Find the question that gets asked constantly and answered slowly. Not the most important question. The most repeated one. In distribution it is usually some version of “which of these part numbers supersedes which,” and the person who knows is one human being who took Friday off.
- Go find out where that answer actually lives today. Not where the process document claims it lives. Somebody will say SharePoint and be wrong, and the real answer will turn out to be a spreadsheet three people maintain and nobody owns.
- Count the documents. If version one needs more than a few hundred, you have picked too broad a question. Cut it down until the set is small enough that one person could read all of it in a week, because that person is going to be your quality check.
- Write twenty real questions with known right answers, before you build anything. This is the single highest value hour in the whole project, and everybody skips it. You are building the ruler you will measure with, and if you write it after you have seen the demo, you will unconsciously write a ruler the demo passes.
- Decide who is wrong when it is wrong. Name them. If the answer is “IT,” you have not picked an owner, you have picked a place to route complaints.
Scope it that tight and you are looking at weeks, not quarters. Weeks. Scope it as “all company knowledge” and you get a project that never finishes, staffed by people who quietly stop attending the standup, which is how a build that was supposed to take six weeks ends up in front of its third steering committee eighteen months later with nothing in production.
If you want a structured version of that thinking across your whole stack instead of one use case, the AI readiness scorecard for mid-market operations walks a single real decision through your systems and shows where it snaps. The answer is usually your data, not your model. It always is.
Once the assistant answers reliably, the obvious next move is letting it do something rather than just say something. Different animal, different failure modes, which is why building your first agentic workflow got its own post.
How You Will Find Out It Is Lying
Those twenty questions are not a formality. They are your regression test, and you run them every week. Forever.
When an answer comes back wrong there are only two real causes, and they need opposite fixes. Either the search step never retrieved the right document, or it retrieved the right document and the model ignored it. From the user’s chair those look identical. From the logs they look nothing alike, which is the whole reason you keep logs. Keep the logs.
Require citations on every answer. An answer with no link to a source document is a rumor with good grammar. Treat it that way. It also converts skeptics faster than anything else I have tried. The first thing a skeptic does is click through and check. The second thing they do is stop checking, once it has held up four or five times.
Make “I do not know” an acceptable answer. Most demo configurations are tuned to always produce something, which is a great way to win a bake-off and a terrible way to run a business.
One more, and it comes up constantly. If retrieval keeps surfacing the wrong customer record, or three versions of the same vendor, you do not have a model problem. You have the problem I wrote about in AI data cleaning, where the assistant faithfully reports a mess you have been carrying since 2019. No amount of prompt engineering fixes a duplicate. Ever.
Where the Bill Actually Lands
Three tiers, roughly.
A custom GPT or a packaged assistant sitting over a document library is a per-seat subscription and a couple of weeks of somebody’s attention. Genuinely the correct first move for most companies, and there is no shame in it. None at all.
A retrieval build over a controlled document set with real permissions is a project. Weeks of engineering, a hosting bill that is small, and a long tail of index maintenance that is not.
Then there is the tier where it reads your ERP live, and that is where the surprises are. Two are worth naming because they blow up schedules. Your API call allowance is a hard number, and a chatty assistant querying per question instead of working from a synchronized copy will eat it, which is arithmetic rather than opinion and something I broke down properly in that ERP post. And then the one that catches everybody. A NetSuite RESTlet will not accept a plain API key, it wants signed OAuth, so an API-key-only tool needs an authenticated relay standing in front of it. I have watched that single detail add two weeks to a build. Twice. The wider version of this problem sits in NetSuite integration best practices.
The line item nobody budgets is the seat. Somebody has to re-index when documents change. Somebody runs the twenty questions every week. Somebody retires the policy that got superseded back in March, which nobody else will remember to mention, and fields the “why did it say that” emails without getting defensive about them, and I have yet to meet a mid-market org chart with a spare hour in it for any of that. Ten hours a month if the scope stayed small. A real job if it did not stay small.
This is the thought I asked you to hold. That seat is the most common reason a working assistant quietly goes stale, and it is a hiring decision, not a software decision. It sits somewhere between data stewardship and internal tooling, which is an awkward shape for a job description. KORE1 fills IT roles in 17 days on average and keeps 92 percent of those placements past the twelve-month mark, and they can scope this on a contract basis first if you are not ready to commit headcount to something you have not proven yet. For the build itself the market has settled on a few titles, and LLM engineers are the ones who have actually shipped retrieval systems rather than read about them.
What Comes Up in the Second Meeting
Our Microsoft rep says Copilot already does this. Does it?
Partly. And for a lot of companies, partly is enough. Microsoft 365 Copilot reads what a given user can already read across SharePoint, Teams, and Outlook, and it inherits their permissions properly, which is the hardest part of this entire problem solved for you out of the box. Where it stops is anything living outside that estate. Your ERP, your PLM system, your product catalog, a contract archive in some legacy repository. If your question lives inside Microsoft, buy Copilot and skip the project. If it lives in NetSuite, Copilot is not reaching it.
Where does the money actually go on a build like this?
Nowhere near where people expect. Model usage is usually the smallest line on the invoice. Often a rounding error against the rest. The money goes into getting documents into a state worth indexing, into rebuilding permissions inside the index, and into connectors. Budget roughly two thirds of a first build to plumbing and cleanup, one third to everything that looked like AI in the demo. Anybody quoting you the reverse split has not done one.
It answered a question wrong in front of our CFO. Now what?
Good. Cheap lesson, loud room. Go read the logs that same afternoon and find out whether the right document was retrieved and ignored, or never retrieved at all, because those are different bugs. Then add that exact question to your test set so it cannot happen twice. What you must not do is respond by widening the document set, which is the instinct every single time and makes precision worse, not better.
Can it read NetSuite directly, or does it need a copy of the data?
Both work, and version one should almost always run off a synchronized copy. A nightly extract into a searchable store is cheaper, faster to query, cannot take your production instance down on a bad day, and does not burn API calls every time somebody gets curious. Go live against the system only when the answer genuinely has to be current to the minute, which is rarer than people claim in the meeting. The NetSuite MCP connector has changed what that live path looks like, and it repays an hour of reading before anybody hand builds an integration they did not need.
Do we have to shut down the personal ChatGPT accounts first?
Wrong order. Banning them first is how you lose. People use those accounts because they work, so a ban without a replacement pushes the same behavior onto phones you will never see. Give them something internal that answers a question they actually have, make it faster than the workaround, then write the policy. Sequencing matters more here than the policy wording does.
When should we kill it?
When six weeks go by and nobody has asked it anything. Usage is the only metric that has ever told me the truth about an internal tool. It decays before satisfaction scores do, and long before anybody admits in a meeting that they went back to asking Dave. If the questions dried up, either you picked the wrong question or the answers stopped being trustworthy, and both are worth finding out quickly rather than at renewal.
My Corn Bot Still Gets More Feedback Than Most Pilots
That is a joke. With something real underneath it. CORN-GPT gets used because it does one absurd thing consistently, and anybody who opens it understands exactly what it is for inside four seconds.
Most internal assistants get built the other way round. Broad scope, vague promise, a launch email, silence. Then a quiet retirement.
So do the boring version. Write your twenty questions this week, on paper, with the right answers next to them. If you cannot fill twenty, you have not found the problem yet and no amount of tooling is going to hide that. If you fill twenty in ten minutes, you have just scoped the entire project, and you did it without a vendor in the room.
Then send me the list. Genuinely, hit me up on LinkedIn, because I read them and the patterns across companies are fascinating. And if the list is solid but nobody in the building has the hours to own the thing once it works, that stops being a technology question and becomes a job description, which is where KORE1’s recruiters can help you scope the seat.
Let’s graduate the tech stack from the 90’s to at least the 2000’s. Twenty questions and a corn joke, if you need one.
