Editorial guide

Before You Build an Agent, Build Your Approved Process

An agent can follow a bad process faster and more consistently than your team ever could.

That is the danger when automation starts before the process is settled. A support team wants an agent to handle account-access requests. The demo works. The agent reads the request, checks a few fields, and chooses whether to reset access or escalate.

Then the real cases arrive.

The public help article says Support can reset access after verifying the account owner. The internal runbook says Security must review every domain change. Recent tickets show senior agents approving some resets without Security. A CRM note says one customer has a custom approval path. A Slack or Teams thread warns that former-employee requests must never use the standard reset flow.

Which instruction should the agent follow?

A generated workflow can make this material look complete without resolving the disagreement. An execution tool can then apply that polished workflow at scale. The failure did not begin with the agent. It began when an unclear process was treated as an approved one.

Before you automate the work, you need to know what the team has actually approved, where the exceptions are, who owns the gray areas, and which cases should remain human decisions.

A plausible workflow is not an approved process

AI workflow and SOP generators are useful for getting past a blank page. Give one a prompt and it can produce a tidy sequence with steps, owners, and decision branches.

That draft may still be wrong in ways that are hard to see.

It may:

assign an owner who never accepted the responsibility
repeat a stale rule from an old runbook
turn a one-time exception into standard policy
omit a branch that only appears in recent tickets
choose one of two contradictory macros without showing the conflict
invent a clean escalation path where the source material never defined one
describe what usually happens without saying what must never be automated

The problem is not that the draft looks rough. The problem is that it can look finished.

An approved process needs more than complete sentences and numbered steps. It needs evidence from the work, visible uncertainty, a person with authority to decide, and a recorded review outcome.

The real process is spread across the work

Most teams already have process material. It just does not live in one reliable document.

The current rule may be split across:

support tickets that show how edge cases were handled
SOPs and help articles that describe the standard path
macros or saved replies that agents actually send
CRM notes that change the answer for particular accounts
onboarding or customer-success notes that explain a prior promise
call transcripts where someone describes the workaround
Slack or Teams threads where an owner approves an exception
an experienced employee's memory of what happens when the normal path breaks

Any one source can tell a convincing but incomplete story.

Tickets show real behavior, but old behavior is not automatically policy. A runbook shows intended procedure, but it may be stale. A macro shows what customers hear, but it may promise something the owning team cannot deliver. A transcript can explain the exception while leaving out who approved it.

The job before automation is to bring a bounded set of this material together and turn it into drafts that show where each rule came from. Those are source-backed drafts: proposed SOP steps, decision rules, and escalation rules that a human can trace to the underlying tickets, notes, macros, documents, or threads.

What the review layer should catch

The review layer is the work between gathering the source material and allowing a person or tool to rely on the resulting process.

Before an agent acts, your team should be able to answer five questions:

What work is this process allowed to cover?
What source material supports each important rule?
Where do the sources disagree or leave a decision open?
Which items are approved, rejected, or still being edited?
Who is accountable for the final decision?

If those answers are missing, the agent brief is incomplete no matter how polished the workflow looks.

1. The boundary

Name the team, function, queue, or operating area covered by the process. “Customer operations” is too broad. “Account-access requests handled by Support for existing business customers” is narrow enough to review.

A boundary prevents an approved rule for one team or case from quietly becoming a company-wide rule.

2. The evidence behind each rule

The person reviewing the draft should be able to see why it says Support may reset access after one form of verification but must escalate after a domain change. That person is the reviewer: the human who decides whether the draft is ready to reuse.

If that rule came from three recent tickets and a current runbook, show that context. If it came from one old thread, label the evidence as thin. A polished sentence should not receive more confidence than its sources deserve.

3. The gaps and conflicts

Do not smooth disagreement into one confident paragraph.

For the account-access example, useful findings might be:

the help article and internal runbook disagree about Security review
recent tickets contain exceptions, but no source says who approved them
the CRM contains custom approval paths that the standard macro ignores
no source names the owner for requests involving a former employee
the response macro promises a same-day resolution that Security does not promise

These findings are not editorial cleanup. They are business decisions waiting for an owner.

4. The approval state

Every important item should have a clear status: draft, approved, rejected, or needs edit.

“Needs edit” matters because a rule can point in the right direction and still be unfit for reuse. The escalation may be correct while the customer-facing promise is wrong. The standard path may be ready while the former-employee branch remains unresolved.

An export should preserve that distinction instead of presenting every generated item as equally trustworthy.

5. The accountable human

Name one person who can decide what becomes the process.

That might be the Head of Support, a Support Operations Manager, an onboarding owner, a RevOps lead, a security owner for access requests, or a COO in a smaller company. The title matters less than the authority to approve, edit, reject, and keep questions open.

If nobody owns the decision, the process is not ready for an agent. Automation would only hide the ownership gap.

A practical pre-automation review

You do not need a company-wide documentation project before testing one agent candidate.

Use this sequence:

Choose one bounded area. Pick one team, function, queue, or operating area where automation would be useful this week.
Gather the real material. Bring the tickets, docs, macros, notes, transcripts, CRM notes, exports, and Slack or Teams threads that people use when handling the work.
Draft the operating guidance. Turn the material into proposed SOP steps, decision rules, escalation rules, reusable replies, and open questions, with source context attached where available.
Expose uncertainty. List missing owners, stale instructions, contradictory sources, unsupported steps, and cases that should not be automated.
Review item by item. Have one accountable owner approve, edit, reject, or mark each item as needs edit.
Export only what is ready. Give the downstream team or automation tool the reviewed guidance, along with the unresolved cases that must still escalate to a person.

Do not turn this into a “clean up all our knowledge” project. The goal is one reviewable set of operating guidance for one bounded source set, not a perfect model of the whole company.

Workflow generators and execution tools solve different jobs

A workflow generator helps create a draft. That is valuable when the process is known but unwritten.

An agent-orchestration or automation tool helps carry out steps across systems. That is valuable when the actions, boundaries, exceptions, and escalation rules are already clear.

Neither job replaces process ownership.

If the team has not decided which source wins, who approves exceptions, or which cases require human judgment, the missing product is not a more capable agent. The missing product is an approved process.

This distinction helps you choose the right tool for the problem in front of you. You do not need to ask whether a documentation tool or an agent platform is “better.” Ask what stage the team is actually at:

If the process is approved but unwritten, draft it.
If the process is approved and the execution boundary is clear, automate the appropriate steps.
If the process is scattered, contradictory, or ownerless, review it before doing either.

Where Company Brain fits

This is the gap Company Brain is built to handle: structured operating knowledge before automation.

You bring one bounded set of source material from a team or function. Company Brain uses it to draft SOPs, decision rules, escalation rules, reusable macros, internal FAQ entries, and optional notes for a skill file that an agent can use later. It also surfaces gaps, conflicts, stale guidance, and open questions instead of hiding them inside a smooth summary.

Together, those drafts and findings form an operational knowledge pack: a review workspace that shows the proposed guidance, its source context where available, and its current approval status.

One named owner reviews the items. They can edit, approve, reject, or mark them as needs edit before exporting the reviewed result.

Company Brain does not execute the workflow or act as an agent platform. It prepares the reviewed operating layer that a human team can use now and that a later automation project can depend on.

For the account-access example, the useful result is not “an agent that resets access.” It is a reviewed pack that tells the team:

which verification steps are approved
which domain changes require Security
which account-specific terms change the standard path
which former-employee cases must stay human-led
which reply language has been approved for reuse
which conflicts still need a decision

That pack can improve the current support process even if the agent project pauses. If automation proceeds, the team starts from rules it has actually reviewed.

What to bring to the first run

Choose one bounded team or function source set connected to a real use this week.

Bring:

the tickets, docs, macros, notes, transcripts, CRM notes, exports, or Slack or Teams threads people currently rely on
examples where the normal path broke, an exception was granted, or ownership became unclear
one person who can review and approve the resulting guidance
one planned use for the reviewed pack this week, such as updating an SOP, replacing a macro, clarifying an escalation path, improving onboarding guidance, or preparing a safer agent brief

Ordinary confidential operational material can be used for one bounded trial scope. Do not include secrets, credentials, payment data, regulated health, legal, or financial data, private employee records, highly confidential strategy, or anything your company cannot share under its obligations.

If you have the source material, the reviewer, and a use planned this week, start the free trial.

Build the approved process first. Then decide what deserves automation.