02 / How we work
Four steps, from the process you want fixed to a flow that’s secured.
01
Discover
We start with the processes you want to improve — how they run today, who carries them, and where the cost sits.
02
Teach
We show your people where today’s AI models can assist and where it shouldn’t, so the decisions are yours to make.
03
Modernize
We rebuild the flow through your existing systems where possible, with AI doing the parts it genuinely does better.
04
Secure
We secure the new flow and hold it: monitoring, access, evidence, and runbooks your team can carry.
Selected work
What we ran, and what changed.
Engagements run by Process Weave principals. Client details withheld.
8+ source systems mapped
Weeks, not months
Support in days, not quarters
01
Group and subsidiaries · Construction materials · Ongoing
Security Foundation
Operational Assurance
The foundation the AI work had to sit on
Situation
A group of operating companies on Microsoft 365, each subsidiary running its own footprint. Endpoint protection with nobody watching it. Microsoft’s own protections half-configured. No visibility into what left the network, including, it turned out, to AI tools.
What we ran
Modernized the foundation instead of replacing it. Configured the Microsoft tenant to do what it was already licensed to do. Put controls on what leaves the network. Consolidated management and remote access.
What changed
AI use on company devices now runs through a controlled path with policy and training attached. Before, nothing could see what left the network, so any policy would have been a document.
Read the detail
Everything above this layer assumes the environment underneath is sound. If identity, egress, and endpoint aren’t right first, AI adoption widens the blast radius of problems already there.
Coverage is end to end:
The network edge, and everything leaving it
Every endpoint on it
Every identity using it
Every device carrying it
A gap in one makes the others decorative. What sits in each is a vendor decision, chosen for real escalation paths and for what they let us hand off, because a small provider can’t staff an overnight analyst seat.
The egress layer is where the foundation and the AI work meet. The same control that filters web traffic determines which AI tools reach the network, so when the AI policy was written the mechanism to enforce it was already deployed.
Almost everything at this size runs on Microsoft 365, and we harden what’s there. A lot of what’s missing isn’t a product nobody bought. It’s capability already licensed and never switched on.
Same architecture at forty staff, fewer sites.
02
Shared services · Construction materials · Ongoing
AI Governance
Operational Assurance
Shadow AI, closed at the network and at the desk
Situation
Staff were already using consumer AI tools on company devices. No policy governed it, nothing on the network could see it, and new tools were arriving faster than any annual review cycle.
What we ran
Authored the AI policy with HR alongside a rewritten IT policy, and rolled out DNS and proxy enforcement on the same schedule. Ran a real evaluation before sanctioning one assistant. Granted access by role and demonstrated need.
What changed
Unsanctioned tools no longer reach the network. The permitted path is one platform, provisioned deliberately, with training attached, and the boundary holds without anyone policing it.
Read the detail
A written AI policy is a document, and a document doesn’t stop a browser tab. Policy writing has been commoditized: templates are free and law firms will sell you one. Enforcement hasn’t been.
Three things went out together:
The policy, written with HR against the group’s actual obligations
DNS and proxy controls, making the boundary real on the same schedule
One sanctioned assistant, chosen after testing several against the group’s actual work
That last one mattered downstream, because training tuned to a single tool beats training tuned to a category. Access went by role and demonstrated need rather than a department-wide switch-on, so the people with a real use case got it, with training attached.
The same work at sixty staff: one policy against your obligations, controls that make it enforceable, one tool chosen because it fits how you work. Most providers do the first and skip the second.
03
Group and subsidiaries · Construction materials · Ongoing
AI Enablement
Operational Assurance
Training that gates access
Situation
Staff were curious and unsupported. Left alone that resolves three ways, all bad: people use AI quietly and badly, dismiss it after one wrong answer, or trust it past the point where it needs checking.
What we ran
Built a curriculum delivered live and in person, with written material. Attendance is mandatory before access is granted. Sessions cover the ground rules, then how the models actually work, then use cases tuned to the room.
What changed
People bring uncertainty to us instead of resolving it alone. Sessions now run on use cases staff raise themselves, delivered on site, including to teams of under a dozen.
Read the detail
The session runs in a deliberate order:
Ground rules first, so they don’t get lost behind the demo
What the model is actually doing, and why the output is the most likely continuation and not a correct one
Use cases tuned to the room, drawn from their own work
Where it fails, and what to watch for
People who understand it’s probabilistic check its work. Showing someone where a tool breaks earns more trust than showing them where it shines, and it determines whether they can be left alone with it.
Curriculum is tuned per audience. Finance, HR, sales, operations, IT, and a subsidiary each got their own version, revised as the tools moved. Later sessions came from staff: two people wanted to know what was possible with a spreadsheet, so we took their real problem and walked the room through how we’d work it.
The measure isn’t a completion rate. It’s that people ask before doing something uncertain instead of hiding it.
04
Shared services · Construction materials · Ongoing
AI Enablement
Discovery
Knowing what to point it at
Situation
Financial and operational data lived in systems built decades ago, with the business rules in code rather than documentation. The people who could explain them had moved on. Nothing could be replaced safely until it was understood, and understanding it was conventionally months of work.
What we ran
Recognized the problem as one AI could carry and scoped it accordingly. Mapped the legacy data flow end to end across eight-plus sources, a subject matter expert working alongside Claude. Traced every element of every existing report back to its origin.
What changed
One to two weeks instead of months, alongside other work. Every reporting element accounted for back to source, validated data landing in the new platform, parity now a matter of filling in known pieces.
Read the detail
The judgment came before the work. A legacy estate nobody fully understands normally gets handled by throwing people at it, or by rebuilding narrow and hoping.
The model read the whole estate far faster than any person could and held all of it in view at once.
It stumbled where you’d expect:
Category codes defined nowhere in the system
Obsolete values that had stopped meaning anything years ago
Which systems and which people actually own a given piece of data
None of that is recoverable from code, because it was never in the code. So the work was neither automated nor manual: one to two weeks, alongside other responsibilities, with someone who knew the business steering.
Without the map, the rebuild would have been reporting built as narrow slices, each solving the report in front of it, followed by substantial rework once the gaps surfaced.
At smaller scale the estate is different and the judgment is identical: the practice management system with fifteen years of history and three people who half-remember the customizations. Nobody can change it because nobody fully knows what it does.
Engagement intake