AI Copilot Development & Digital Workforce
A general assistant can write a summary. It does not know what your finance manager is accountable for on Monday. We build assistants around one role — its knowledge, its systems, its recurring work and the limits on what it may do unsupervised.
- Who
- Delivered by a senior team assembled for the engagement, against a defined scope.
What you're seeing
- An enterprise assistant licence went to every employee and no number moved.
- Usually means The purchase was made per seat, so the return has to show up as individuals working faster at unspecified things. Nobody defined the work it was meant to change, which means nobody can tell whether it did.
- Senior specialists spend most of the week assembling information.
- Usually means The expensive part of the role is judgement and the majority of the hours go to retrieval, formatting and chasing. The ratio is usually worse than the people doing it believe, which is why it is worth measuring rather than estimating.
- The same report is rebuilt by hand every week from the same four sources.
- Usually means A recurring, fully specified piece of work is being done manually because it needs a small amount of interpretation at the end. The interpretation is the job; the assembly is not.
- Output quality depends noticeably on who did the work.
- Usually means The process lives in individual practice rather than in a shared standard. That is fixable, and encoding the better practice into the tooling is a more durable fix than training.
- New joiners in the role take months to become independently useful.
- Usually means Ramp is gated on knowing where things are and how they are usually done, neither of which is written down. That knowledge transfers socially, at the pace of the person doing the mentoring.
Context is the whole product
Ask a general assistant to prepare next week’s supplier review and it will produce something plausible and useless, because it does not know which suppliers, which contract terms, which thresholds trigger a conversation, or where last quarter’s review ended up.
A copilot that is useful knows those things. That knowledge is not a longer prompt — it is a connection to the systems that hold the answers, an identity that decides what this person may see, and a specification of the work the role repeats.
Built around one job
The starting point is observation rather than a workshop. What does this role produce every week, from which sources, with how many touches, and where does it wait? That produces a list of recurring work with times attached, which is both the design input and the baseline.
From there, the copilot gets the approved knowledge the role relies on, the role’s own permissions through your identity provider, access to the systems it works in, a description of its recurring tasks, the tools it may call, and thresholds that say what needs confirming.
Finance, operations, sales, procurement, project management and customer success are the roles this shape suits most often, because their recurring outputs are documents someone already reviews — which means the quality bar is observable rather than theoretical.
Not one per employee
The licence-everyone strategy has already been run at most companies and it is the reason the current conversation is sceptical. It produces broad shallow usage, no measurable change, and a renewal discussion nobody can argue either side of.
The alternative is narrower and less exciting: pick one role where the workload can be counted, redesign that role around the combination of human judgement and automated preparation, measure it, and use what was built for the second role. The platform underneath — retrieval, identity, the tool layer, the evaluation set — is most of the work, and it is paid for once.
Where it sits
A copilot is the internal-facing shape within AI & Automation, and it sits on top of two other things on this list. It needs the knowledge layer to be useful, which is enterprise RAG and is usually built first or alongside. And where the recurring work is a multi-step process that runs to completion without a person in the middle, that is not a copilot at all — it is AI agent development, and the distinction is whether a human stays in the loop by design.
That distinction decides more than the architecture. A copilot is adopted or ignored by the person it was built for, so its success depends on whether it fits the way they already work; an agent runs whether anyone likes it or not, and its success depends on the error rate. The first is a product problem and the second is an engineering one, and treating a copilot as though it were an agent is the most common reason a technically sound assistant sits unused after the launch email.
What this covers
Each of these is a capability with its own page, its own order of work and its own outputs.
| Capability | What it means |
|---|---|
| AI App Development | LLM features that hold up in production. An evaluation set before the feature ships, cost controlled by design, and data boundaries settled before a provider is chosen. |
How we decide
The copilot acts under the user's identity, not its own
Costs Some capabilities cannot ship until the role's access is properly modelled, which delays the first useful version.
A shared service identity makes every action untraceable to a person and grants the assistant a union of everyone's rights. Running as the user means it sees what they see, does what they may do, and appears in the audit trail as their action — which is also what makes it safe to let it write anything.
Preparation is automated before decisions are
Costs The result is less impressive to demonstrate than a copilot that appears to decide.
The reliable value in knowledge work is in assembly — pulling the four sources, reconciling them, drafting the recurring artefact, flagging what looks unusual. It is high-volume, low-risk and verifiable. Automating the decision is where the failure is expensive and where the person's accountability makes them the correct bottleneck.
Scope is one role at a time, not one department
Costs Coverage grows slowly and other teams wait.
A copilot is useful in proportion to how specifically it understands one job — the recurring work, the vocabulary, the systems, the thresholds. Widening the scope to a department averages all of that away and produces something closer to the generic assistant the organisation already had. The second role is much cheaper because the platform underneath is already built.
Copilots against the alternatives
Every option here increases someone's capacity. They differ in what they know about the job and whether they can act.
| Approach | Knows the role | Can act in systems | When it wins |
|---|---|---|---|
| A role-specific copilot | Yes — work, thresholds, systems, vocabulary | Yes, under the user's own permissions | Many people doing the same specialised process |
| Enterprise chat licences | No | No | Drafting, summarising and general reasoning |
| An internal prompt library | Partly, wherever someone wrote it down | No | A cheap first step that reveals what is worth building |
| Hiring an analyst | Yes, after a ramp | Yes | Work that needs accountability and genuine judgement |
The prompt library row is worth taking seriously. It costs almost nothing, and the prompts people actually reuse are a better specification for a copilot than any workshop.
Is this you?
- A group of people run the same knowledge-work process with local variation
- Expensive specialists spend the week assembling information rather than deciding
- An enterprise chat licence went to everyone and nothing measurable changed
- A general writing assistant, which you can buy
- A role nobody can describe in terms of recurring, observable work
- Organisations that want one assistant for every role at once
How we run it
One role, measured, before a second
We instrument what the role actually spends time on before designing anything — usually a week of observation and a review of the artefacts the role produces. It routinely contradicts the job description, and it is the only way to know afterwards whether the copilot moved the workload or just added a tool.