Build a workflow someone else can run

Esther asked who updates the shared context after a meeting changes a decision.

We were talking about using agents across a product team. She already used Claude Code for research, analysis and writing. Getting useful output was familiar territory. Keeping that work useful as the team and its decisions changed was harder.

Later, Antonio described another problem: people try the new way of working, get stuck, and bring the work back to the person who knows the tools. The champion becomes the help desk. When everyone gets busy, the old process returns.

I recognize the temptation to answer both questions by adding more instructions. There is always another case to explain, another document to connect. But if I remain the person who interprets every exception, I have not made much of my way of working available to anyone else.

So this is where I would start building a company harness: give a colleague one recurring piece of work they can complete without me beside them.

Pick work small enough to inspect

Take a weekly review of customer evidence. A PM reads recent calls and support threads, checks them against current product decisions, and proposes what to investigate next.

That is a useful first workflow because we can inspect the sources and the proposed next step before anything reaches a customer. It also contains real judgment. Summarizing every request accurately still leaves the team to decide which problem deserves attention.

Choose something you already do. If it works well with your current tools and a short handover, keep that arrangement. Extra machinery needs to solve a problem you can name: repeated explanation, missing evidence, conflicting decisions or work returned for the same reason.

For this example, imagine a B2B product whose workspace administrators struggle to invite colleagues. Someone has requested bulk invitations. We have two recent interview notes, a support thread, a current product decision and a note about access restrictions. This is a fictional exercise, not a customer case.

The task is to propose the next investigation. Building bulk invitations is only one possible outcome of later work. Download the practice files for the agent and keep the case guide, which includes expected answers, for the reviewer.

Give the work a small, explicit agreement

I would put the following note beside the source material. It can live in your existing project space; there is no need to reorganize the company first.

Weekly invitation review

Question: What should we investigate next about inviting colleagues, and why?

Use: Interview notes INT-01 and INT-02, support thread SUP-01, current decision DEC-01 and access note ACC-01. Preserve these IDs in the result so a reviewer can open the exact source.

Produce: One proposed next investigation, the evidence supporting it, evidence against it and the important unknowns. “We need to clarify this first” is an acceptable result.

Limits: Work from the supplied material. Do not contact customers, change the roadmap, alter access settings or treat a request as an approved decision. Flag missing information.

Review: The PM responsible for invitations accepts, returns or stops the proposal. That decision must be recorded before further work starts.

Save: Keep the proposal with its source references and the review outcome. Retain the prior decision if the owner changes it.

This note describes the work. Access controls must make its limits real. Start with a sanitized source packet if you have not verified the agent's live access. An instruction saying “do not send” is not a security boundary when the same agent still holds unrestricted sending credentials.

For this exercise, the agent can write a local proposal. It does not need write access to your support system, roadmap or customer accounts.

A repository is one place you might store these materials. Codex or Claude Code can run the task. The sources, permitted actions, checks and review process around that task are the beginnings of a company harness. Keep that agreement when you change agents, then test that the new setup respects it. Portable files do not guarantee equivalent behavior.

Make the example awkward

An easy packet will produce a reassuring demo. Include something that needs interpretation.

Suppose INT-01 describes an administrator trying to invite a whole department. SUP-01 repeats that same administrator's complaint. INT-02 describes a different administrator who cannot understand why an invitation failed. DEC-01 records a decision to investigate invitation failures before expanding invitation volume. ACC-01 says some invitations require approval from an account administrator.

A weak result counts three requests and recommends bulk invitations. It has counted one customer's problem twice and skipped the current decision.

A result worth reviewing might say:

INT-01 and SUP-01 describe the same incident, so they are one customer signal. INT-02 suggests a separate problem with understanding failed invitations. I propose observing administrators through a failed invitation and recovery attempt before choosing a bulk flow. DEC-01 supports that investigation, but we do not yet know whether failures are common or whether participants had the required permissions. The PM should confirm the research scope before anyone contacts customers.

This is an example of an acceptable response, not an output from a completed test. A colleague could disagree with the proposed investigation and still produce good work. What matters is whether they can show their reasoning, identify the uncertainty and respect the current authority to decide.

Now change one thing. A meeting proposes a different priority, but approval is unclear. Add the meeting note while leaving DEC-01 in the packet.

The agent should surface the conflict. The responsible person must confirm whether the new decision supersedes the old one and update the current record accordingly. A newer file can contain a suggestion, a misunderstanding or an unapproved plan. Its date alone cannot settle the matter.

Let someone else run it

Ask a colleague to use the packet and workflow note. Resist supplying the missing explanation in chat halfway through. Notice where they stop and what they need from you.

When they finish, inspect the proposal together. Can they open the source behind the recommendation? Did they recognize the repeated incident? Can they explain what the agent was allowed to do, who decides next and where the review result belongs?

Record the review outcome in plain language. For example: “Returned: establish whether the interview participants had invitation permission before choosing the study.” Include the relevant source or missing fact, the next action and its owner. A rejection with a reason gives the next run something to improve. A thumbs-down does not.

Run it again after fixing the most consequential gap. If the work still returns to you for interpretation every time, keep it small. That is useful information about what you have not yet made transferable.

Keep what earns its place

You do not need a fleet of agents to learn from this exercise. You need to see whether a second person can produce work you can review without reconstructing the entire task yourself.

A folder of notes may be enough at first. Later, duplicated records might justify an integration; repeated source mistakes might justify an automated check; a slow review might justify a different output format. Add those pieces when you can point to the failure they address.

That is the series I want to work through: which context counts, how to limit actions, how to test the result, and how to keep the work useful when decisions and people change. The architecture is described in Build the Harness That Outlives the Agent. This exercise gives us a small place to put it to work.

Where Zentrik fits

This weekly review is the job Zentrik is built for. It reads the sales calls, support tickets and research you connect, ranks the ideas already in your backlog against that evidence, and finds the needs your backlog does not cover. Your team checks the sources and decides what to investigate or test. The customer evidence guide shows where to start.

If you try it, I would like to know where your colleague needed you. That is a better starting point for the next improvement than another tool recommendation.