Rebuilding is the default because nothing is designed to be reused
An organisation runs its first AI project with a small team and a reasonable amount of latitude. The second is staffed by somebody who has never seen the first and is given the same instruction: build something for this process. By the fifth, the organisation has several working systems, several definitions of the same concept, and no way of knowing whether they agree.
Nobody chooses this. It happens because reusable work is harder to fund than a specific project, harder to describe to a sponsor, and harder to show in a quarterly review. A project has an outcome and a date; a capability has neither.
Reuse begins with a shared business model rather than shared code
The most valuable reusable asset in an enterprise AI programme is not a library or a service. It is a settled set of definitions: what a customer order is, which fields it has, which system is authoritative for each one, what an exception is, which state a transaction is in. Without that, every project invents its own vocabulary.
Producing it is slow, unglamorous and largely organisational. It requires a person from the business to say which definition is right, and a place to record the decision so the next project inherits it. The distinction between database access and usable business context is in why an AI agent needs more than database access.
Connectors are the part that pays for itself twice
A connector is not glamorous, and it is the component that most often decides whether a second project is cheap or expensive. It knows how to read a system of record, write a transaction back, authenticate as the user on whose behalf the system acts, respect that user's permissions, and behave when a schema changes.
Written once per source system, a connector removes a category of work that would otherwise be repeated in every project, and concentrates the difficult decisions where they can be reviewed once. The risk is that it becomes a general-purpose integration platform with no owner, so the discipline is a small named set, each with an owner and a stated scope.
Workflow patterns turn separate builds into a menu
Most enterprise processes are one of a small number of shapes: read information from an unstructured source and produce a structured record; read a record and propose a decision for a person to confirm; read a queue, prioritise it and route it; produce a periodic summary of something already measured. If each project invents its own version, the organisation ends up with a dozen ways of doing the same thing.
A pattern is worth defining once: its inputs, its output contract, the evidence it retains, the approval it requires, its failure behaviour and its exception path. Once a pattern has working instances, each new project becomes a configuration of existing pieces. The pattern is in enterprise agent engineering.
Controls and test methods are what make reuse safe
Reuse without controls is a liability, and reuse without tests is a risk nobody can argue about. Both are where an enterprise programme improvises, because the pilot was small enough for a person to check its output.
- Evidence retention as a pattern, so that every action carries the input that produced it and the rule under which it was taken.
- Approval and escalation as configuration, so that which decisions need a person is decided once per business process rather than per application.
- A regression suite per pattern, holding the cases that broke in production, so a change to a shared component is visible before it reaches dependent processes.
- A review cadence per shared component, with a named owner accountable for its quality and its retirement.
The test method matters as much as the control. A shared evaluation set for a pattern turns an argument about whether a new build is good enough into a comparison of two measured results, which is the only form of that argument a sceptical executive accepts. Without it, every project is judged on its own terms.
Delivery standards turn a project into a repeatable engagement
The last element of a capability is procedural, and it decides whether a second project is faster than the first. Standards for how discovery is run, how a process is baselined, how a design is reviewed, how a build is handed over, and how cost is estimated all shorten the second engagement.
A shared model is only reusable if it has an owner outside the project team, and only trustworthy if a change to it is a versioned decision rather than an edit. That separates a capability from a folder of documents, and it is the argument of shared business context.
A sequence for building the first reusable layer
The temptation is to build a platform before any project needs one. The workable sequence is the reverse: build the first project, extract from it, and let the second project fund the extraction.
- Complete one project end to end in production, with its controls, evidence and owner, so there is a real instance to generalise from.
- Identify the three components that would have been identical in the second project: the business model, the connection to the source system, the workflow shape.
- Extract each one, document its contract, and give it a named owner. The test of success is that the second project uses it rather than copying it.
- Add the evaluation set for the pattern, with the cases that broke in production.
- Move the controls into the pattern, so approval, evidence and escalation are configured rather than rebuilt.
- Re-run the second project against the shared components and record the difference in effort, so the value of the layer is visible.
The measure of this work is not the number of components in a catalogue. It is the time and cost of the second project relative to the first, and whether the second inherited the first one's learnings rather than repeating its work.