The company brain
How your own staff teach the system a job
Last updated
Short answer
A skill is a job taught once that anyone can then invoke by asking. The person who knows how the job should be done works through it in conversation, corrects the output until it is right, then asks the system to keep what it just did. No developer is involved. This is the mechanic that makes the system worth more in month twelve than in month one, and it is the reason what your people know stops leaving when they do.
Definition
What a skill actually is
A skill is a written procedure the system holds and can carry out on request. It records what the job is, where the material for it comes from, what good output looks like, and the corrections a person made the first time it was run. It is stored as text, which matters more than it sounds: you can read it, edit it, argue with it, and take it with you.
The important part is who creates one. Not us, and not anybody technical. The person who already knows how the job should be done creates it, in ordinary language, in the course of doing the job once.
That distinction is the whole difference between a system you own and a system you rent access to.
If teaching it a new job requires a call with your supplier, it is not your system.
The loop
The four steps of teaching one
This is not a configuration screen, and there is nothing to fill in. It is a conversation that ends with a request.
- 1Do the job with it, once, properlyThe person who knows the work walks through it in conversation. They point it at the right material, tell it what it missed, and correct the tone, the format and the omissions until the output is genuinely what they would have sent.
- 2Ask it to keep what it just didIn plain language: turn that into something we can reuse. The system writes down the procedure it followed, including every correction, and stores it under a name people will recognise.
- 3Anyone invokes it by askingThe next person who needs that job done asks for it. They do not need to know it exists as a formal thing, who built it, or how. They ask for the outcome and get it.
- 4It improves on every runA correction made on Thursday is part of the procedure on Friday, for everyone. Nobody has to remember to update anything, because correcting the output is the update.
The economics of it
Why this is the part that compounds
Most software is worth the most on the day it is installed and slowly less afterwards, as the business moves and the software does not. This inverts that, for one structural reason: the asset being accumulated is written by your own people about your own work, and it accumulates whether or not anyone is thinking about it.
| Month one | Month twelve | |
|---|---|---|
| What it can do | One or two jobs, scoped narrowly | The jobs a team actually repeats |
| Who taught it | Us, working alongside two of your people | Your people, mostly without us |
| Quality of output | Roughly right, corrected often | Corrected rarely, because past corrections are in the procedure |
| What happens when someone leaves | The job leaves with them | The job stays and the next hire asks for it |
| What you own | A connected system | A written record of how your company does things |
The second row is the one worth watching. If after a quarter every new skill still originates with us, the onboarding did not take and the system has a single point of failure that is not inside your company. That is a failure worth catching at three months rather than at eighteen.
The retention argument
What happens when the person who knew leaves
Every company has jobs that exactly one person can do well. Preparing a particular kind of quote. Handling the supplier who always sends the wrong paperwork. Knowing which of three conflicting documents is the one that is actually current. None of it is written down, because writing it down was never anyone's priority and the person who knows it is busy doing it.
When that person resigns, the standard response is a handover period in which they attempt to transfer years of accumulated judgement in two weeks, mostly verbally, to someone who does not yet know which questions to ask.
Where the jobs have been taught to a shared system, the handover is different in kind rather than in degree. The successor does not have to be told; they ask.
Institutional knowledge stops walking out of the door on somebody's last day.
This is also the honest sales argument for doing it before you need it. The month somebody hands in their notice is the worst possible month to start.
The honest no
Which jobs make bad skills
Not everything should become one, and a system full of skills nobody invokes is worse than a system with four that everyone does.
- Jobs done once a yearBy the time it comes round again the procedure is stale and the business has moved. The effort of maintaining it exceeds the effort of doing the job.
- Jobs where the answer is genuinely a judgement callIf two experienced people in your company would answer differently and both be defensible, you do not have a procedure, you have a decision. Teaching it produces confident output that is sometimes wrong in ways nobody catches.
- Jobs whose source material nobody trustsA skill built on a document set that is out of date faithfully reproduces the out-of-date answer, at speed, to everyone. Fix the material first.
- Jobs that are one broken process in disguiseIf the job exists only because a system upstream does not talk to a system downstream, connect those two. Teaching the workaround makes the workaround permanent.
The good candidates are boring: frequent, disliked, well understood by at least one person, and built on material that is current. Start there, not with the impressive one.
Frequently asked questions
Does creating a skill require a developer?
No, and if it does then the design has failed. The person who knows the work creates it in conversation, in ordinary language. Two or three people are trained to do this during onboarding, which is what stops every future job from coming back to us.
What if somebody teaches it something wrong?
It is a written procedure, so it can be read, corrected or deleted like any other document. The realistic risk is not a malicious skill but a stale one, which is why reviewing what people actually ask and where the answers are wrong is part of running the system rather than an optional extra.
Can we take the skills with us if we stop working with you?
Yes. They are text, and they are yours. That is deliberate: the valuable asset is the written record of how your company does things, and a supplier who locks that up is selling dependence rather than a system.
How many skills does a company end up with?
Fewer than people expect, and that is the healthy outcome. A team that repeats six jobs weekly gets more from six well-maintained skills than from sixty that nobody trusts. The honest measure at three months is how many your own people created, not the total.
Do skills work across departments?
They can, and the access layer is what makes that safe. A skill can be available to everyone, to one team, or to named roles, and it inherits the same per-person checks as any other request.
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.
Start with one job your team repeats
The useful first conversation names a specific job somebody does weekly and dislikes. If it turns out that job is a judgement call rather than a procedure, or that the material behind it is out of date, you will hear that before anything gets built.