The company brain
How a rollout actually runs, stage by stage
Last updated
Short answer
Four stages, in order, and the first is a document rather than a build. A written blueprint agreeing what the system will know, connect to and deliberately not touch. Then the connections and the material. Then training two or three of your people to teach it new jobs without us. Then keeping it current. The honest measure at ninety days is how many jobs your own people have taught it, not how impressive the first demonstration was.
The shape of it
The four stages
- 01
Blueprint
What the system will know, what it will connect to, which jobs it does first, who is allowed what, and what it will deliberately not touch. Written down and agreed before anything is built. This is a deliverable you keep whether or not the build follows.
- 02
Connections and material
Connecting to the tools you already run and organising the material the system answers from. This is where the real condition of a company's documentation becomes visible, and it is normal for it to be worse than anyone expected.
- 03
Team onboarding
Training two or three of your people to teach it new jobs themselves. Without this the system has a single point of failure and that point is your supplier.
- 04
Running it
Keeping the material current, adding and retiring jobs, and reviewing what people actually ask and where the answers are wrong. A system nobody maintains degrades quietly.
Week by week
What the first ninety days look like
Indicative rather than contractual, and the shape holds more often than the dates do.
| When | What happens | What you should have at the end of it |
|---|---|---|
| Weeks 1 to 2 | Scoping conversations with the people who do the job, not only the people who sponsor it | A named first job, an owner inside your company, and a number that counts as working |
| Weeks 2 to 4 | The written blueprint, including what is deliberately excluded | A document you could hand to another supplier and get a comparable quote |
| Weeks 4 to 7 | Connections built, material organised, access mapping agreed with whoever owns security | A system answering real questions from real material, in front of a small group |
| Weeks 6 to 9 | The first job taught, corrected in use by the people who do it | Output the person who owns that job would have sent themselves |
| Weeks 8 to 11 | Your two or three people trained to teach it new jobs | At least one job taught entirely without us |
| Week 12 | Review against the number agreed in week 2 | A decision to widen, hold or stop, made on evidence rather than impression |
Your effort
What is needed from your side
Less than most companies fear, but not nothing, and the parts that matter cannot be delegated to us.
- One owner inside the companyA named person whose job it is to care whether this works. Not a committee. A system with no internal owner drifts within a quarter regardless of how well it was built.
- Access to the people who actually do the jobNot only the people who sponsor the project. The gap between how a process is described upstairs and how it runs is where most of these projects go wrong.
- Two or three people willing to be trainedThey do not need to be technical. They need to know the work and be willing to correct the system when it is wrong.
- A decision from whoever owns securityEarly rather than at the end. The access design is easier to agree before it is built than to retrofit after a demonstration everyone liked.
- Tolerance for the first fortnight being unimpressiveEverything of this shape starts roughly right and is corrected into being useful. A first demonstration that looks perfect was scoped to look perfect.
From experience
What goes wrong, in order of frequency
- The material is in worse condition than anyone believedConflicting versions, superseded policies nobody withdrew, procedures that describe a process that changed two years ago. This is the most common single cause of a slipped timeline, and it is discovered in stage two rather than stage one.
- The access decision arrives lateA build that has to be reshaped after security reviews it loses weeks. Bringing that conversation forward costs nothing and is the single cheapest risk reduction available.
- The first job was chosen because it demonstrates wellImpressive jobs are usually rare, judgement-heavy or both. Pick the frequent and disliked one instead, even though nobody will applaud it.
- Nobody inside the company gets trainedUsually because the trained people were busy in the weeks the training was scheduled. It is worth moving other things to protect, because the alternative is a permanent dependency nobody decided to take on.
- The sponsor changesThe owner leaves or moves and nobody inherits the caring. This is the most common reason a working system quietly stops being used, and it has nothing to do with the technology.
The measure
How you know at ninety days whether it worked
Three questions, answered honestly, and none of them is about the software.
- How many jobs have your own people taught it without us? If the answer is none, the onboarding failed, and that is fixable but only if it is named.
- Is the first job being used by the people who do it, or by the person who sponsored it? Sponsors demonstrate systems. Practitioners use them, and only their usage predicts anything.
- Against the number you agreed in week two, did it move? Not whether it feels faster. The number.
If the honest answers are no, the correct decision is to stop or narrow rather than to widen and hope.
A system that has not been adopted in ninety days is not going to be adopted in the fourth month by being given more to do.
Frequently asked questions
Can we buy only the blueprint?
Yes, and some companies should. It is a document describing what would be built, what it would connect to and what it would deliberately avoid. It is useful for deciding whether to proceed at all, for comparing suppliers on the same basis, and for taking to a board that has asked what the plan is.
How long does the whole thing take?
A first bounded job is usually working within a quarter. A shared system covering several teams is a longer arc, and the honest reason is rarely the build: it is the condition of the material and the pace at which access decisions get made inside the company.
What if the blueprint concludes we should not do this?
That is a legitimate and reasonably common outcome. The most frequent versions are that the procedures have never been written down, or that the real problem is one broken process. Both are cheaper to hear at the end of stage one than at the end of stage four.
Do you need access to everything to start?
No, and it is better if you do not give it. The blueprint names what gets connected for the first job and what stays out of scope. Widening happens later, deliberately, once there is evidence the first thing works.
What happens after the first ninety days?
Either the system widens to more jobs and more teams, or it holds where it is and gets maintained, or it stops. All three are legitimate. The one outcome worth avoiding is drifting on without anybody making the decision, which is what happens when no number was agreed at the start.
AINORA, MB builds and operates AI systems for companies from Vilnius, Lithuania. It designs company brains: shared internal systems that hold an organisation's own knowledge, connect to the tools it already runs, and carry out the jobs its people repeat, with access rights enforced per person and hosting in the EU.
The first conversation is scoping, not selling
What comes out of it is a view on whether there is a job here worth building for, and if there is, what the blueprint would have to settle. If the answer is that your material is not ready, you will hear that first.