Turn the work your experts can do with AI into a capability the wider team can use. Keep the context, the quality checks and the judgment that made the first result useful.
Plan the cost of building and running a workflow
Claude Code, Codex and GitHub Copilot can contribute changes to a repository. The repository keeps the work available for inspection and further development.
Each tool still needs its own instructions, access and checks. A shared destination does not make their behaviour identical.
Move repository changes through tests that address the intended behaviour. Useful tests give the team evidence about what the change actually does.
Carry lessons from failures into the next iteration. A passing test result supports review but does not make the whole release decision.
Human review checks whether the change serves its purpose and fits the surrounding system. It is a distinct decision after the automated checks.
Give the reviewer enough context to assess the result. That includes what changed, what was checked and what remains uncertain.
Governed access defines who and what can act on the repository. Keep that responsibility explicit as the next iteration begins.
Check the authority for the next action before work continues. Permission to propose or test a change does not automatically include permission to release it.
Coding tools, a repository, tests, human review and governed access form a repeatable delivery pattern. Each contributes a different part of the control.
Use failures and review findings to improve the shared way of working. The next change should benefit from what the team has already learned.
Claude Code, Codex and GitHub Copilot can contribute changes to a repository. The repository keeps the work available for inspection and further development.
Each tool still needs its own instructions, access and checks. A shared destination does not make their behaviour identical.
Move repository changes through tests that address the intended behaviour. Useful tests give the team evidence about what the change actually does.
Carry lessons from failures into the next iteration. A passing test result supports review but does not make the whole release decision.
Human review checks whether the change serves its purpose and fits the surrounding system. It is a distinct decision after the automated checks.
Give the reviewer enough context to assess the result. That includes what changed, what was checked and what remains uncertain.
Governed access defines who and what can act on the repository. Keep that responsibility explicit as the next iteration begins.
Check the authority for the next action before work continues. Permission to propose or test a change does not automatically include permission to release it.
Coding tools, a repository, tests, human review and governed access form a repeatable delivery pattern. Each contributes a different part of the control.
Use failures and review findings to improve the shared way of working. The next change should benefit from what the team has already learned.
Give an agent a defined change, the context to make it and a way to check the result. The team still decides what should change and when it is ready. Matt builds this way with Claude Code, Codex and this site's maintained wiki.
Set the development scope for Claude Code, Codex and GitHub Copilot around the work they may perform. The organization still owns the decisions about code, data and release.
Configure and test the controls each tool supports. Shared policy intent needs separate checks wherever identities, permissions or execution environments differ.
Access controls determine who and what can reach the repository. Assign access around the work that each person or tool needs to perform.
Review those assignments as the team and workflow change. Agent-assisted development still needs a clear owner for access decisions.
Data controls define the information available to development work. Consider that scope alongside repository access.
Make the rules understandable to the people maintaining the workflow. Controls need to be configured and checked in the tools that enforce them.
Repository changes proceed to human review. That decision considers the result in the context of the task and its access and data boundaries.
Retain useful review findings with the working method. They help the next iteration address the same responsibility more clearly.
Tool choice, repository access, data scope and human review belong to the same delivery process. None of them removes the need for the others.
Start with explicit responsibilities and verify the controls in the actual environment. Expand the workflow only with a clear understanding of what those controls cover.
Set the development scope for Claude Code, Codex and GitHub Copilot around the work they may perform. The organization still owns the decisions about code, data and release.
Configure and test the controls each tool supports. Shared policy intent needs separate checks wherever identities, permissions or execution environments differ.
Access controls determine who and what can reach the repository. Assign access around the work that each person or tool needs to perform.
Review those assignments as the team and workflow change. Agent-assisted development still needs a clear owner for access decisions.
Data controls define the information available to development work. Consider that scope alongside repository access.
Make the rules understandable to the people maintaining the workflow. Controls need to be configured and checked in the tools that enforce them.
Repository changes proceed to human review. That decision considers the result in the context of the task and its access and data boundaries.
Retain useful review findings with the working method. They help the next iteration address the same responsibility more clearly.
Tool choice, repository access, data scope and human review belong to the same delivery process. None of them removes the need for the others.
Start with explicit responsibilities and verify the controls in the actual environment. Expand the workflow only with a clear understanding of what those controls cover.
Decide what a good result must do and check the work against it: tests verify behaviour, experts judge whether the result is useful. A failed check retries within its allowance, goes to a specialist or stops for a person. Keep useful failures as regression cases.
The wiki holds the knowledge the team should use now. Getting started, architecture and procedures explain the business context and how the work fits together.
Give each subject a maintained home. People and agents need to distinguish the current answer from an old discussion about it.
Discussion records retain chat history, ideas and reviewed decisions. They explain how the team reached a conclusion when someone needs to revisit it.
Carry accepted facts into the wiki as decisions settle. Keep the reasoning available without making every new task replay the conversation.
The agent harness holds skills, commands and workflows. These instructions describe repeatable work and the checks that make its result useful.
Maintain the method when a failure exposes a gap. The next task should receive the corrected guidance as well as the current facts.
Outputs include research briefs, meeting notes and status reports. They put the maintained knowledge to use for a specific decision or task.
Review those outputs before relying on them. Bring useful findings back into the wiki or working method so they can inform later work.
The wiki carries current facts, discussion retains reasoning, the harness holds methods, and outputs serve the work. Each collection has a different purpose.
Together they give a second brain context that an expert can inspect and maintain. That organization is what lets the next task begin with less repeated briefing.
The wiki holds the knowledge the team should use now. Getting started, architecture and procedures explain the business context and how the work fits together.
Give each subject a maintained home. People and agents need to distinguish the current answer from an old discussion about it.
Discussion records retain chat history, ideas and reviewed decisions. They explain how the team reached a conclusion when someone needs to revisit it.
Carry accepted facts into the wiki as decisions settle. Keep the reasoning available without making every new task replay the conversation.
The agent harness holds skills, commands and workflows. These instructions describe repeatable work and the checks that make its result useful.
Maintain the method when a failure exposes a gap. The next task should receive the corrected guidance as well as the current facts.
Outputs include research briefs, meeting notes and status reports. They put the maintained knowledge to use for a specific decision or task.
Review those outputs before relying on them. Bring useful findings back into the wiki or working method so they can inform later work.
The wiki carries current facts, discussion retains reasoning, the harness holds methods, and outputs serve the work. Each collection has a different purpose.
Together they give a second brain context that an expert can inspect and maintain. That organization is what lets the next task begin with less repeated briefing.
A skill carries the instructions, examples and checks that make a task repeatable, so the next person or agent can pick it up. When an expert corrects the work, review the change to the shared source. Skills carry across tools; the workflow still needs testing there.
Map the content people will use and the access they already have. Establish ownership before introducing the workflow to a wider group.
The assessment gives the first rollout a defined scope. It also identifies the questions that testing needs to answer.
Begin with a limited cohort using scoped content. This gives the team a manageable setting for learning how the workflow behaves.
Keep the purpose and boundaries clear to the participants. Their experience should contribute evidence for the next decision.
Review the evidence from the limited rollout and resolve the findings that matter. The decision concerns readiness for the next scope of use.
A date on the calendar is not that evidence. Keep expansion tied to what the review has established.
A wider rollout follows the review decision. Choose the next group and content scope with the lessons from the first cohort in view.
Continue collecting useful findings as the audience grows. A successful first stage does not settle every condition of wider use.
Access reviews, content owners, policy checks and audit continue across the rollout. They are ongoing responsibilities rather than a one-time launch gate.
Use the sequence to make each expansion decision explicit. The scope grows as the evidence and ownership support it.
Map the content people will use and the access they already have. Establish ownership before introducing the workflow to a wider group.
The assessment gives the first rollout a defined scope. It also identifies the questions that testing needs to answer.
Begin with a limited cohort using scoped content. This gives the team a manageable setting for learning how the workflow behaves.
Keep the purpose and boundaries clear to the participants. Their experience should contribute evidence for the next decision.
Review the evidence from the limited rollout and resolve the findings that matter. The decision concerns readiness for the next scope of use.
A date on the calendar is not that evidence. Keep expansion tied to what the review has established.
A wider rollout follows the review decision. Choose the next group and content scope with the lessons from the first cohort in view.
Continue collecting useful findings as the audience grows. A successful first stage does not settle every condition of wider use.
Access reviews, content owners, policy checks and audit continue across the rollout. They are ongoing responsibilities rather than a one-time launch gate.
Use the sequence to make each expansion decision explicit. The scope grows as the evidence and ownership support it.
Give experts room to develop and test a workflow within their role's quotas, then check that someone else can run it and handle exceptions. A national insurer's website content was converted by a purpose-built transpiler, then migrated in two weeks with no specialist needed at handoff.
A small team can develop a workflow using Claude Code or Codex. Proving it means understanding its useful result and the conditions it needs.
Keep the knowledge from testing and review with the workflow. That gives the next team something more dependable than a successful demonstration.
Package the proven workflow with the instructions and knowledge needed to operate it. Make the responsibilities clear enough for another team to take on.
Decide what must change for the destination environment. Reuse of the working method does not guarantee direct code compatibility.
For a Microsoft 365 team, an agent in Copilot can provide a place to use the workflow. Adapt and test the supported connections, knowledge and access for that destination.
Confirm what the intended users can complete and where an expert must still intervene. Wider access is useful only if the team can operate the workflow and judge its results.
The pattern moves from a proven small-team workflow through deliberate packaging to organizational use. Each stage needs its own evidence.
Preserve expert ownership as more people begin using the workflow. Useful feedback from operation should improve the maintained version.
A small team can develop a workflow using Claude Code or Codex. Proving it means understanding its useful result and the conditions it needs.
Keep the knowledge from testing and review with the workflow. That gives the next team something more dependable than a successful demonstration.
Package the proven workflow with the instructions and knowledge needed to operate it. Make the responsibilities clear enough for another team to take on.
Decide what must change for the destination environment. Reuse of the working method does not guarantee direct code compatibility.
For a Microsoft 365 team, an agent in Copilot can provide a place to use the workflow. Adapt and test the supported connections, knowledge and access for that destination.
Confirm what the intended users can complete and where an expert must still intervene. Wider access is useful only if the team can operate the workflow and judge its results.
The pattern moves from a proven small-team workflow through deliberate packaging to organizational use. Each stage needs its own evidence.
Preserve expert ownership as more people begin using the workflow. Useful feedback from operation should improve the maintained version.
For a team in Microsoft 365, plan how a proven workflow reaches people through Copilot: the task, the knowledge it needs and the authority users should have. Keep its sources, checks and escalation rules, then adapt and test the connections for the destination.
Give each workflow an owner, an access boundary and a budget. Review accepted results, failures and human effort alongside token use, and revisit checks and quotas as the work changes: a new model or a wider audience is a reason to test again.
Choose one workflow that already helps an expert. We help make its knowledge reusable, define the checks and quotas, and work out what wider use would take.
Take a workflow that already helps an expert, capture its knowledge as reviewed skills, and define the checks and quotas it needs.
Plan how a proven workflow reaches more people, including Microsoft 365 Copilot where it fits, with owners, access boundaries and budgets.
A workflow the wider team can run and check.
At enterprise scale, Matt plans and shadows an implementation partner. Smaller scopes can be delivered directly with him.
Start with one workflow that already helps an expert.