ICYMI
One Company, a Thousand Workflows – Employees are building their own AI tools and workflows. Left private, unowned and disconnected, they become a new class of legacy system.
Executive Summary
AI allows employees to design and build their own workflows faster than colleagues can understand how they fit together.
Employee-made tools can unintentionally omit verification steps or create downstream issues for other teams.
Companies can empower employees to innovate by enforcing clear rules for how workflows interact with each other and by building a process for updating those rules.
AI can help find tools, dependencies and gaps, but management must set the rules and ensure accountability.
The technology for this exists. The focus should be on deciding who owns the rules and on funding the services that enforce them.
The Great Fire of London destroyed 13,200 houses in 1666. In its aftermath, Christopher Wren proposed a design for a new London, inspired by Paris, with broad avenues and piazzas. His plan was never adopted due to property rights, compensation costs and the need to get merchants back in business quickly.
Instead, London was largely rebuilt using its existing street map, but under new rules. The 1667 Act categorised streets by type (e.g., high streets, lanes), required brick or stone construction and specified building heights and the design of party walls between neighbouring properties. Surveyors enforced the requirements, a coal levy paid for the public works, and a special Fire Court settled disputes between landlords and tenants over who should pay for construction. By the end of 1670, about 6,000 houses had been rebuilt. Individual builders could get on with their work because these shared arrangements (rules, funding and a way to settle disputes) were in place.
Later, in 1847, sewer connections became compulsory for new buildings. These sewers discharged into the Thames. As more properties connected, their combined waste became a growing public-health hazard. Cholera returned in 1853–54, followed by the Great Stink of 1858. Intercepting sewers were eventually built to carry waste away from central London.
Now, companies face a similar challenge as AI allows more employees to build and update their own workflows. Each tool may suit its creator, yet have a detrimental impact on the organisation as a whole, for example by making customer promises that can’t be kept, causing bottlenecks downstream, or introducing autonomous work that is hard to audit.
Prescribing every working method would curtail employee-led innovation. London’s evolution suggests a more effective approach: leave people free to design their own methods, while the company takes responsibility for the rules and services that allow them to work together.
Everyone Can Build, But Consequences Are Shared
At Centrica, Nishant Jain led application development for the finance team, but did not consider himself technical. Nevertheless, his team built an application in two months to coordinate tax returns across regimes, replacing a manual process that relied on emails. Centrica scaled this employee-led development approach. By 2021, it had more than 1,000 applications across the business, up from around 300 two years earlier.
As this example shows, employee-led invention predates generative AI. But AI changes who can build software, how quickly they can revise it, and the reach of the tools that they build. Low-code tools lowered the barrier to building, but AI lowers it further, and agents can choose and sequence actions on the company’s behalf. An employee can now change a workflow in hours. But other teams may still be working on the assumption that the workflow behaves as it did yesterday.
In many organisations, coordination between teams still happens informally. Colleagues check stock and delivery capacity before anyone commits to a delivery date, for example. This ‘human middleware’ is liable to fail when workflows change rapidly.
Enabling individual innovation whilst maintaining smooth operations requires the boundaries between teams to be formalised and the checks that protect the wider organisation (e.g., checking stock and delivery capacity before promising delivery) to be made explicit.
Four Things the Company Must Provide
1. Provide common handovers between tools. London’s party-wall rules required builders to leave ‘toothing’ brickwork so the next house could join seamlessly. Employee-built tools also need agreed connections. For each recurring type of work passed between teams, the managers of those teams must agree what information is handed off.
For example, sales and engineering might agree and publish a standard customer brief including customer requirements and the requested delivery date. Sales employees are then free to build their own sales workflows, provided that the output conforms to the agreed brief. On the other side of the handover, engineering employees can also build their own workflows, taking the data in the brief as a starting point.
However, a handover standard is insufficient in three important cases:
When multiple tools compete for the same resource, such as stock or an engineer’s time.
When a tool commits the company to something, such as a price or a delivery date.
When a tool changes a record that other teams rely on, such as a customer’s details or a supplier’s bank account.
In these cases, two tools that conform to an agreed handover standard can still conflict because they act independently. That is when the company needs a core service: a shared method that allocates, commits or updates on everyone’s behalf.
2. Provide core services that enforce the business rules. London’s houses depended on shared streets and public works. In the three cases discussed above, employee-built workflows need to access a core service.
For example, a mandatory quotation core service might dictate prices and reserve stock when called by an employee-built sales tool. Employees can still gather requirements, compare options, and prepare the offer in many different ways, while the same pricing and reservation rules apply to every offer.
The core services themselves enforce business rules because instructions to the AI are not enough on their own. Where an employee-made tool can make promises to customers, that action must also follow the authorised route. Each core service needs an owner and a budget.
3. Make workflows and core services visible. London’s new buildings were visible to everyone. Employee-made tools are harder to see. Every company needs a register of its homegrown methods, core services, and handover specifications, with their owners and dependencies. It also needs common definitions for terms such as ‘customer’ and an auditable way to trace information back to its source. Core services and handover specifications also need to be visible so that employee-builders can access them quickly.
4. Check methods before and after deployment. London’s surveyors checked new buildings against the rules. Companies need to routinely check for permissions, approved connections and adequate fallback arrangements. The level of scrutiny should reflect how widely a method is used, the sensitivity of its work and whether mistakes can be reversed. Repeat the relevant checks when workflow logic, standing instructions, models, dependencies, or permissions change. Test representative journeys across connected tools and core services, including failed handovers and competing requests. Someone independent must periodically confirm that the controls work and exceptions are visible.
Much of This Can Be Automated
It takes effort to set up these mechanisms, but much of their day-to-day administration can be automated. AI tools used by employees can be set up with templates and connections to core services. Permissions can be set to prevent employee-built tools from accessing core systems directly.
The company’s managed tech platforms can be set to automatically register new employee-built tools and run routine checks whenever they change. AI can help maintain the register of tools by examining code, instructions, and activity records to deduce what each tool does and what it depends on. It can also flag missing information or changes that need attention. It will not see everything, so periodic manual reviews will still be needed.
By mid-2026, Centrica’s ‘Front Door’ system was detecting new app and workflow development within its Power Platform environment, asking creators about each tool’s purpose, users, and risks, and calculating a risk score. Higher-risk projects were sent for human review. Centrica also extended the same controls to AI agents, governing who could access them and how they could be published.
Old Solutions, New Problems
None of these mechanisms is new. Around 2002, Amazon issued a mandate requiring teams to communicate through service interfaces rather than access databases directly, according to former engineer Steve Yegge. Software architects have written service contracts and kept catalogues for years.
What is new is that AI increases the number of people who can change workflows and the frequency with which they do so, making it hard to review every change. Employees can now create far more powerful tools, for example, by spinning up AI agents that act autonomously and vary behaviour depending on context. Model updates or retirements can change behaviour even when the employee hasn’t changed the workflow. Business rules that colleagues once applied through judgement increasingly need to be explicit and enforced whenever a tool takes action.
Different Tools, Common Rules
Let’s take a couple of examples. Suppose two salespeople have built different quotation tools. Both see one item available and promise it to a customer. Each tool works as intended, but the company sells the same item twice. Both tools can continue to exist if they call a core reservation service. That service allocates the item once, so the second salesperson gets a refusal or a proposed alternative.
The same principle applies to supplier management. A marketing team might build a tool to onboard freelance designers, while a factory builds one for maintenance contractors. Each tool gathers different information, suited to its work. To ensure the right controls are followed, tools should use a core supplier-registration service. It checks whether the supplier already exists, routes the necessary checks to the accountable people and records the outcome.
Build the Service Before Making It Compulsory
London’s compulsory sewer connections show how individual compliance can concentrate problems in infrastructure that is not equipped to handle them.
Requiring employee-built tools to use an approved core service makes that service a dependency for everyone using it. If it is slow, unreliable or unable to handle the demand, that creates an issue for the whole business. A core reservation service that works for one sales team may struggle when hundreds of tools begin calling it automatically.
Management must fund core services to meet demand and provide fallbacks if they fail. If completing a routine task through the core service takes two days while bypassing it takes ten minutes, employees have a strong incentive to work around it. So the service must be built, tested and sized for demand before tools are required to use it.
The Rules Must Be Able to Change
Employees will quickly discover better ways of working that the core services do not yet support. If they can build a tool in an afternoon but changing a core service takes six months, their freedom to innovate is limited. They need to know how to request a change, who can approve it and when to expect an answer. Core service owners need funding for improvements as well as day-to-day operation.
Tools may also need updating when an AI model is withdrawn, a security flaw is found or business requirements change. The register should show which tools are affected and who is responsible for updating them. A central update may fix the connection to a replacement AI model, but every affected workflow still needs to be re-tested.
Before changing a core service, give teams that depend on it time and support to adapt. The old and new connections may need to run alongside each other for a fixed period. AI can help find dependencies and suggest repairs, but owners remain responsible for checking the results.
London’s rebuilding needed clear rules, funded public works and people responsible for maintaining them. Companies need arrangements that employees can rely on, and a practical way to change them as the business learns. Together, these make an organisation evolvable.
Monday Morning Actions for Executives
Set the direction. Encourage employee-built tools but specify the rules for such innovation.
Clarify accountability. Each core service needs a named business owner accountable for its rules, service levels, and evolution. The CIO is accountable for the supporting technology and technical controls.
Assess the health of existing core services. Check that they provide the required level of service and are adequately funded.
Make the rules open to challenge. Give employees a route to propose changes and require owners to respond.
Questions for the Board
Where could employee-built tools drive improvements to our operations?
Is employee-led innovation enabled and contained by clear boundaries and rules?
Do we have an assessment of the risk to operations presented by employee-built tools?
Can our core services and rules change as fast as our employees do?
Sources
University of Oxford, Faculty of History. “Facing up to catastrophe: The Great Fire of London”. Fire losses and the pace of rebuilding.
Hebbert, M. “The long after-life of Christopher Wren’s short-lived London plan of 1666”. UCL. Why Wren’s plan was not adopted.
Statutes of the Realm, vol. 5. “An Act for rebuilding the Citty of London” (1667). Building rules, surveyors and the coal levy.
Statutes of the Realm, vol. 5. Fire of London Disputes Act 1666. The court for resolving rebuilding disputes.
The London Archives. “Drainage applications and plans”. The introduction of compulsory sewer connections.
Hansard (1858). Debates of 15 July and 19 July. Parliamentary funding for London’s sewer works.
London Museum. “How Bazalgette built London’s first super-sewer”. The sewage crisis and Bazalgette’s response.
Microsoft (2021). “Centrica leverages Power Apps to ensure its solutions are futureproof”. 22 November. Supplier-published case study of employee-built applications at Centrica.
Microsoft (2026). “Centrica drives a new wave of Power Platform innovation with Managed Environments and Copilot Studio”. 19 June. Supplier-published account of Front Door, risk reviews and AI agents.
Yegge, S. (2011). “Stevey’s Google Platforms Rant”. His account of Amazon’s service-interface mandate.
Evans, E. (2003). Domain-Driven Design. Background on boundaries between systems.
Skelton, M., and Pais, M. (2019). Team Topologies. Background on platform teams and ownership.
Anthropic (2024). “Building effective agents”. 19 December. The distinction between workflows and agents.
Microsoft. “Model migration”. Guidance on testing and adapting applications when models change.