Build the Brain and the First Workflow at the Same Time

A company AI brain and the first useful workflow should be built at the same time. The workflow proves that the effort changes real work. The brain preserves the context, rules, and evidence the workflow uncovers so the next system does not start from zero.

Building only the workflow creates a pile of isolated prompts and agents that carry conflicting copies of the business. Building only the brain creates an increasingly polished archive that has never been forced to produce a correct result. The two have to discipline each other: real work tells you what the brain must know, and the brain gives real work a governed foundation it can reuse.

What a company AI brain is—and is not

A company AI brain is an owned, maintained body of operating context that people and agents can retrieve before they work. It may include:

• the company map and operating vocabulary;
• current processes, accountable owners, and known exceptions;
• authoritative systems, files, fields, and evidence sources;
• policies, decision rules, and escalation boundaries;
• approved examples and evaluation cases;
• reusable skills or runbooks;
• records of decisions and what they superseded; and
• receipts showing what actually ran and what the system read back.

It is not a custom model. It is not every document the company has ever created. It is not a chatbot's conversation history, and it is not a vendor portal that becomes the only place the company knows how it operates.

The format can be a repository, wiki, database, or deliberate combination. I prefer interconnected plain-text files for durable operating knowledge because people can read them, version control can show changes, and different models can use them. But the storage choice is secondary. What matters is that the company owns the source, names what is authoritative, can retrieve the right portion, and has a way to keep it current.

That last point matters because more context is not automatically better. Anthropic's guidance on context engineering treats context as finite and recommends a minimal but sufficient set of instructions, tools, and canonical examples, with additional material retrieved when needed. A useful brain is therefore an organized source and retrieval system, not a giant prompt.

Why a workflow by itself becomes a context problem

An isolated automation can look excellent. Give it one prompt, a clean sample, and a patient operator, and it may produce an impressive result.

The weakness appears when a second or third workflow arrives. One system prepares a quote, another drafts a work instruction, and another summarizes exceptions. If each carries its own copy of customer rules, product terminology, approval limits, and source-system definitions, drift is inevitable. A rule changes in one prompt but not the others. An operator corrects a recurring error, but the correction never reaches the rest of the system. A new model or vendor requires the company to reconstruct its operating context again.

The problem is not merely memory capacity. It is ownership. Which version of the rule is current? Who may change it? Which database field wins when two systems disagree? Which part is a recommendation, and which part is a non-negotiable policy?

OpenAI's guide to building agents recommends deriving routines from existing operating documents, defining actions clearly, capturing edge cases, and establishing evaluation baselines. Those pieces become far more reusable when they live in maintained company context instead of being buried inside one agent configuration.

As the number of workflows grows, context becomes infrastructure. Without a shared foundation, every addition also adds a new place for the business to contradict itself.

Why documenting the whole company first also fails

The opposite extreme sounds disciplined: document everything before an agent touches real work.

That usually captures how the organization believes a process works. It does not reliably expose what an agent needs to complete the job. The unwritten exception appears only when a real input violates the normal pattern. The supposedly authoritative procedure conflicts with the field operators actually use. A person says “we always review that,” but nobody can define what the review checks.

A live, bounded workflow creates useful pressure. It forces precise questions:

• What triggers the work?
• Which source is authoritative?
• What does a correct output contain?
• Who resolves a disagreement?
• Which exception stops the run?
• Which action is reversible?
• What must a person decide?
• What evidence should remain afterward?

NIST's voluntary AI Risk Management Framework Core connects governance, context mapping, measurement, and management as iterative work across the AI lifecycle. Its Map function establishes the context needed to make an initial go/no-go decision, and its Measure and Manage functions turn that context into evaluation and operating decisions. The framework does not prescribe a “company brain,” but it reinforces the underlying point: documentation, context, evaluation, and management are connected activities, not sequential boxes completed once.

Choose one job that can prove the method

The first workflow should be valuable enough to matter and bounded enough to understand.

Good candidates have a recognizable trigger, available examples, a defined output, an accountable owner, and a practical way to check the result. They can usually begin with limited access and reversible actions. They are not necessarily the easiest task, and they are rarely the company's largest transformation.

Use five questions to screen the first candidate:

This is consistent with Anthropic's recommendation to start with the simplest adequate system, measure it, and add complexity only when the evidence justifies the change. OpenAI's use-case prioritization guide similarly uses impact and effort to distinguish opening wins from impressive but slower programs.

If candidate selection is still vague, the guide to picking a first AI project gives a more detailed scoring method. An AI opportunity assessment should go further by preserving the baseline, no-build list, and implementation brief behind the choice.

Build a minimum viable brain around that job

Do not start with a company-wide taxonomy project. Create the smallest shared foundation the workflow needs to operate correctly.

For the selected job, record:

1. Purpose and owner: why the workflow exists and who can judge the result. 2. Trigger and completion: what starts the work and what final state counts as done. 3. Inputs and sources: which files, systems, or fields may be used and which source wins in a conflict. 4. Vocabulary: company-specific names, acronyms, statuses, and distinctions the system must preserve. 5. Rules and exceptions: the normal path, known edge cases, and conditions that require a stop or escalation. 6. Action boundary: what may happen automatically, what remains a draft, and what requires a person's decision. 7. Evaluation cases: representative examples with checkable expected properties. 8. Recovery and receipts: how to reverse or resume work and what evidence proves the actual result.

That is enough to begin. Everything else earns its place by solving an observed problem.

Consider a fictional quote-preparation workflow, for illustration. The first draft of the brain may name the quote owner, the request inbox, the product table, the required output fields, and the rule that no quote is sent automatically. Testing may then reveal that one spreadsheet is only a convenience copy, a part-number suffix changes the pricing source, and rush requests require a separate review. Those verified discoveries belong in the shared system map, glossary, process, and test set—not as one-off corrections buried in a chat.

Use the workflow to grow the brain

Build the first version close to the people who perform the work. Keep the action surface narrow, run representative cases, and capture corrections in two places:

• fix the workflow when the implementation is wrong; and
• update the brain when the organization's durable context was missing or unclear.

That distinction prevents both forms of drift. A parser bug is not a company policy. A newly confirmed approval rule is not merely a prompt tweak.

The loop looks like this:

1. Run one representative case. 2. Compare the deliverable with its source evidence and expected final state. 3. Classify the miss: implementation defect, missing context, conflicting source, new exception, or unclear authority. 4. Correct the smallest appropriate layer. 5. Add or revise the evaluation case. 6. Rerun the case and nearby cases that could regress. 7. Preserve the result and the read-back receipt.

Anthropic's agent-evaluation guidance makes an important distinction here: an agent's trace or completion message is not the same as the outcome in the environment. “Done” is a report. The actual file, database row, delivered artifact, or other final state is the evidence.

A practical first-30-day sequence

The schedule should follow the work, but this is a useful shape for a first implementation:

Week 1: map and baseline

Observe the current workflow with its owner. Gather representative inputs and outputs. Record active time, elapsed time, corrections, and other measures that matter. Define the smallest useful scope and the actions that remain human-controlled.

Week 2: seed and build

Create the minimum viable brain entries, implement the narrow workflow, and run it on controlled examples. Keep sources and evaluation cases separate from generated output.

Week 3: test and correct

Exercise normal cases, exceptions, missing information, and source conflicts. Record durable discoveries in the brain. Fix implementation defects in the workflow. Require evidence from the real output or system state.

Week 4: operate and decide

Run with the intended operator, measure the net result, and make an explicit decision: continue, revise, hold, or stop. If it continues, assign maintainers, monitoring, recovery, and a bounded next expansion.

The point is not the number of days. It is that the brain and workflow reach evidence together. A documentation milestone without a working case is incomplete. A working demo without maintained context, evaluation, and ownership is also incomplete.

Keep the brain alive instead of turning it into an archive

A brain helps only while it reflects current truth.

Give important pages or records an owner. Supersede changed decisions visibly instead of silently rewriting history. Verify drift-prone facts such as provider status, schedules, permissions, and deployed versions against live sources. Keep generated summaries tied to their canonical records. Remove obsolete retrieval paths without erasing unique evidence.

Most importantly, make the workflows contribute maintenance signals. A source mismatch should name the conflicting sources. A failed evaluation should point to the case and changed rule. A completed run should record the inputs, action, result, and read-back. That evidence tells a maintainer what deserves an update.

The system should also retrieve selectively. A quote workflow does not need the entire marketing archive in its context. A content workflow does not need payroll records. Clear file names, paths, metadata, and relationships let the agent load the right source when needed while keeping unrelated or sensitive material out.

What this approach does not solve

Building the brain and workflow together is an implementation method, not a substitute for every control around the work.

• It does not make bad source data correct.
• It does not grant permission to use personal, regulated, confidential, or licensed material.
• It does not turn technical access into business authority.
• It does not prove legal, privacy, cybersecurity, or regulatory compliance.
• It does not make an irreversible action safe because earlier drafts were accurate.
• It does not eliminate maintenance when systems, policies, providers, or models change.

The risk and governance effort should match the actual use. A read-only internal comparison built from copied files is different from a system that sends messages, changes records, commits money, or influences consequential decisions. The production AI agent checklist covers the additional identity, access, monitoring, recovery, and accountability work required before broader operation.

Model-agnostic does not mean model-indifferent

The model and harness still matter. Capability, reliability, latency, tool support, and cost can change the quality of the workflow. The point of an owned brain is not to pretend that every model is equal. It is to prevent the company's operating knowledge, test cases, and decision rules from disappearing when the preferred engine changes.

A migration may require new tools, prompts, or evaluations. But a company that can state what the workflow does, which sources it trusts, how it is tested, where it must stop, and what evidence proves completion has a realistic migration path.

The company brain is the durable operating context. The workflow is the proof that the context can do useful work. Build them together, let each improve the other, and the second workflow begins with a foundation instead of another blank chat.

If you want help choosing the first bounded job and the minimum context it requires, start a free fit conversation.