18 agentic workflows to run against your company brain

Once we set one up, a three word addition to a prompt was all it took: "Ask the workspace."

New to the idea? The Company Brain getting started guide covers the what and the ten minute setup. This article is the deep dive: how the brain answers, how to keep it filled, and eighteen workflows to point at it.

• A company brain is one workspace your agents can ask. A Fastio workspace with intelligence turned on answers a plain English question and cites the document behind every claim, so the agent gets the answer instead of everything it would have had to read.
• Setup takes about ten minutes. Create the workspace, fill it, connect your agent to the Fastio MCP server, then write an "Ask the Brain" skill and make it a reflex in your agent's memory.
• It is agent agnostic and permission bound. Claude Code, Codex, Cursor, Gemini, OpenClaw, anything that speaks MCP. The answer never contains a file the asking identity could not already open.
• Work written back makes the next run cheaper. The brain is storage, so the agent's output lands in it. Every workflow you run leaves the next one less to dig for.
• Start with one workflow. Pick the thing that wasted your time this week, set that up, and let the brain grow around it.

A company brain is a Fastio workspace with intelligence turned on.

Files land in it: contracts, transcripts, specs, exports, decks, notes, screenshots, PDFs, spreadsheets, and everything your agents have written back. They index automatically on arrival. From that point, any agent connected over MCP can ask that workspace a question in plain English and get an answer back with citations pointing at the exact file and passage behind every claim.

One call. The retrieval happens on Fastio's side, over content that is already indexed, so what crosses into your context window is a short cited answer rather than the raw material it was derived from.

Four things make it work as a brain rather than a folder:

It answers, with receipts. Ask the workspace a question and Ripley, the AI built into Fastio, searches the indexed content and writes a plain-language answer with citations back to the source files. You can follow any claim to the document it came from, which is the difference between a useful answer and a confident one.

It finds things by wording, or by meaning. Exact keyword matching for the invoice number and the clause, meaning-based matching for the idea you remember but not the wording. Scope it to one workspace, or sweep every workspace the asking identity can see. Either way the search runs on Fastio's side and comes back as one merged result set.

Structure comes out of unstructured files. Metadata Views extract typed fields from a folder of documents, so a hundred contracts become a table you can query by value: renewal date before September, amount over ten thousand, jurisdiction is California. Your agent stops reading a hundred PDFs to answer a question that was always a filter.

It stays current, and it remembers what changed. New files index on arrival. Upload a new version of an existing file and it re-indexes, while version history keeps the one it replaced. Answers come from what is true now, and you can point Ripley at an older version when you need to know what a file said in March.

Four ways in, and you will probably use all of them.

Upload directly. Drag files into the workspace in the browser, sync a folder with the desktop app, or push them from the terminal with the CLI. Everything indexes automatically once intelligence is on.

Import from the clouds your work already sits in. Bring folders across from Google Drive, Dropbox, OneDrive, or Box with Cloud Import. You can also import straight from a public URL, which is the fastest way to park the competitor's pricing page or a standard your team keeps citing.

Let your agents write into it. The tools you already connect your agents to are also how you stock the brain. Your notetaker, your issue tracker, your CRM: point them at the workspace on a schedule and let them deposit the raw material as it appears.

Let the output land there too. Every brief, synthesis, and draft your agent produces goes back into the workspace as a file. The next agent starts where the last one stopped, and a human can open it, review it, or send it out as a branded link without anyone exporting anything.

That last one is the flywheel. In a normal agent setup, every run starts from zero. Here, every run leaves the next one less to dig for.

The quick version lives on the Company Brain getting started page. Here it is in full. Create the workspace, connect your agent, and make asking a reflex.

Give your agents one place to ask

Create a workspace, turn on intelligence, and connect any agent that speaks MCP. Every answer comes back cited to the source file. Plans start at $29/mo with a 14-day trial.

Start 14-Day Trial

An agentic workflow is a multi-step job you hand over end to end. The agent gathers the context, does the work, and reports back, instead of you running each step by hand and pasting between them.

Every one of these assumes the ten minute setup and the Ask the Brain skill. Copy the prompt, change what is in brackets, run it.

Start with your own team, then skim the others. The best ideas usually come from watching a different department point the same brain at a different problem.

1. Every customer quote you have ever been given

Somebody sent a glowing four-sentence testimonial two months ago. You will never find it again when you need it, because it is somewhere in eighteen months of call transcripts, support threads, and a review nobody saved a link to.

Use the Ask the Brain skill. Find every direct customer quote about [onboarding / pricing / this feature] in the workspace from the last 18 months.

For each quote, return the verbatim line, who said it and which company, the file it came from, and the date. Include the sentence before it so I can see the context. Group by theme, and flag anything that needs approval before it goes public.

Write the result back to /marketing/proof/customer-quotes.md.

Insist on the file and the date every time. Once you have reviewed the list and cut the weak ones, that file becomes the source for every piece of collateral you write, and the next run is one hop instead of a full sweep.

2. Launch in a box

The spec is in a PRD, the reason you are building it is in a decision doc, the demand is scattered across a dozen transcripts, and the positioning lives in a doc somebody changed three times yesterday. Assembling that by hand is the launch, and it is usually why the date slips.

Use the Ask the Brain skill before drafting anything.

We ship [feature] on [date]. Build the launch.

First gather: the spec and scope, the "why we built this" from the decision doc, who has been asking for it and in their words, and our current positioning and tone from the messaging doc.

Then draft, all consistent with that positioning: a blog announcement, a landing page section, a three-email sequence, a one-page enablement doc, a changelog entry, and five social posts.

Cite the source file for every factual claim. Flag anything you had to assume. Write the whole kit back to /launches/[feature]/.

Duplicates are the only real trap. If three positioning docs were touched this week, the agent will pick one and you will not know which. Keep a canonical folder, upload revisions as new versions of the same file rather than as new files, and the agent reads the current one by default.

For a big launch, gather once and then draft each asset separately. Each piece gets full attention, and you get to correct the blog post's assumptions before they travel into the emails.

3. The win/loss engine

Your closed deals are the most expensive research nobody reads. Drop the transcripts and notes into a folder and let the agent read a whole quarter of them at once.

Use the Ask the Brain skill. Read every closed deal in [the last 90 days], won and lost, from /sales/deals/.

Tell me the top five reasons we won, ranked by how often they appear, with a direct quote and source file for each. Same for the top five reasons we lost. Which competitor comes up most in lost deals and what they beat us on. And where the evidence is too thin to trust.

Then turn it into an updated objection handling doc and three specific messaging changes, each tied to its evidence.

Ask for a frequency count behind every line so one loud lost deal does not masquerade as a pattern. Split small deals from large ones, because they lose for completely different reasons and a blended list hides both. If the folder is big, run a Metadata View over it first to pull outcome, competitor, and close reason into a table, then let the agent query the table instead of rereading every transcript.

4. The changelog and the weekly update, written from what shipped

Writing the changelog from memory on a Friday means forgetting half of it and phrasing the other half like a commit message.

Use the Ask the Brain skill for tone and format, and read the repo for what changed.

List every user-facing change merged since [last Friday]. Write a plain-language changelog entry for each, grouped by area, skipping internal refactors and security fixes.

Then draft this week's product update from the same list: a short intro, the three most notable changes with one line each on why they matter to users, and the rest as a list. Match the format and voice of the last three updates in /product/updates/.

Link each entry to its PR, and save the draft to /product/updates/.

PR titles lie, so tell it to read the description and the linked issue for the real reason a change exists. Give it an explicit exclusion list too, or the internal refactors and the quiet security fixes will cheerfully end up in front of customers.

5. Stress test a feature before anyone builds it

Every roadmap has the feature three people swear by that nobody has actually pressure tested.

Use the Ask the Brain skill. We are considering [feature].

Pull every scrap of customer evidence in the workspace: transcripts, support threads, notes, anything. Tell me who is asking for this, how often, and what they actually want, with quotes and source files. Show me where it contradicts a past product decision. Based on the current codebase, tell me what we would have to build. Then make the strongest possible case against shipping it.

Be the skeptic. I want the holes, not the hype.

The skeptic line is the whole workflow. Without it the agent sells your own idea back to you in better words. Feed it your real constraints, engineering capacity and what is already committed, or it will recommend something lovely you cannot build. And make it argue both sides, because it will happily find evidence for whichever side you led with.

6. Fact check the help center against the code

Help articles start lying the moment the code under them changes, and nobody notices until a customer follows step four to a button that no longer exists.

Use the Ask the Brain skill. Pull every published help article from /docs/help/.

For each one, check the behavior it describes against the current codebase. Where they diverge, give me the article, the wrong claim, the correct behavior, and a rewritten version.

Save the rewrites as new versions of the same files so I can compare against what was there before.

Start in review mode and only let it apply changes once you trust the small ones. Remember that a help doc is sometimes simplified on purpose, so tell it not to "correct" an explanation you dumbed down deliberately. Let it fix wording on its own, and keep meaning changes on your desk.

7. The renewal brief, before every call

Walking into a renewal with a vague sense that the account is fine is how you get blindsided.

Use the Ask the Brain skill. [Account] renews on [date]. Build the renewal brief from everything in /accounts/[account]/.

Tell me: what they bought and why, in their own words from the original calls. Every open complaint and unresolved thread. What has changed in tone across the last two quarters of calls. Expansion signals worth raising. And the three risks to flag before I dial in.

Cite the file behind each point. Save the brief to /accounts/[account]/renewal-brief-[date].md.

Drop your usage export in the same folder before you run it and the brief gets sharper, because the agent can line up what they say against what they do. Run a Metadata View across the contracts folder and renewal dates, amounts, and terms become a table you can sort instead of a stack of PDFs.

8. The voice of customer handoff

Support hears every complaint and half-formed request first, and almost none of it reaches product in a shape they can use.

Use the Ask the Brain skill. Read every customer call and support thread in the workspace from [last month].

For the product team, surface: the top requests by frequency, with quotes and which accounts asked. The most common friction points. And anything customers asked for that contradicts what they asked for last quarter.

Format it as a handoff doc with a source link on every claim, and save it to /product/voice-of-customer/[month].md.

Because the output lands back in the workspace, the next month's run reads the last one and tells you what changed, which is the part product actually wants.

9. The renewal risk review

Finding out an account is leaving when they tell you is too late, and reading every account by hand does not scale past about twenty.

Use the Ask the Brain skill. For every account with a renewal in the next 90 days, assess risk from what is in the workspace.

Weigh: sentiment across the last quarter of calls, unresolved complaints, requests we promised and did not deliver, whether our main contact has gone quiet or changed role, and anything in the usage exports in /accounts/*/usage/.

Rank the accounts by risk, show the specific evidence behind each one with its source file, and suggest one save play per high-risk account. Say plainly where you do not have enough evidence to judge.

The champion signal is the one worth wiring in first. Your main contact is usually the reason adoption happened at all, and their going quiet shows up in the transcripts long before it shows up in the numbers.

10. Answer a whole questionnaire in one pass

Security questionnaires and RFPs eat entire days because the answers are spread across policy docs, past responses, and one thread where an engineer explained the real answer.

Use the Ask the Brain skill. Here are [N] questionnaire items: [paste them].

Draft an answer to each one using only what is in the workspace. Return the answer, the source file it came from, and a confidence flag, marking anything you could not verify as "needs human review" rather than guessing.

Match the tone of our previous responses in /sales/questionnaires/. Save the draft as a new file in that folder.

Pin it to the documents and make it flag its own gaps. The answers you correct become the source for the next questionnaire, so this gets faster every time you run it. When it is done, the finished response can go out as a branded link straight from the workspace.

11. The pre-call dossier

The half hour of digging before every call is time you could have spent preparing for it.

Use the Ask the Brain skill. Build a pre-call dossier on [prospect] from everything in the workspace.

Who they are and where the deal stands. Every past touchpoint and what was discussed, in date order. Open questions, blockers, and what they have told us they care about most. The three things to lead with on this call, and the two objections most likely to come up, with the answer to each.

This one is worth the setup cost of getting your meeting recorder to deposit transcripts into the workspace automatically. Once the calls land there, every dossier after that is free.

12. Follow-ups that reference the actual conversation

Outreach goes generic the moment volume goes up. The difference between a good follow-up and a template is whether it references something that actually happened.

Use the Ask the Brain skill. For [lead or list], draft a follow-up.

Pull what we know from the workspace: past calls, notes, documents we sent, anything they told us. For each one: a two line summary of who they are and what they need, a follow-up email that references something specific from our last conversation, and the next best action.

Do not invent detail. If the workspace has nothing on a lead, say so and write the generic version.

The last line is the one that keeps this usable. A personalized email built on a hallucinated detail is worse than a plain one.

Give your agents one place to ask

Create a workspace, turn on intelligence, and connect any agent that speaks MCP. Every answer comes back cited to the source file. Plans start at $29/mo with a 14-day trial.

Start 14-Day Trial

13. Triage everything that got reported

Bugs arrive from a thread, a ticket, an escalation, and a message from a teammate who just wanted to flag something. Half of them rot in place because nobody pulls them into one view.

Use the Ask the Brain skill. Pull every bug and QA report in the workspace raised since [date].

For each: a one line description, the source file, steps to reproduce if they were given, and a severity guess. Group by area of the product. Surface anything reported by more than one person first, and collapse duplicates into a single entry that lists every report behind it.

Save the triaged list to /engineering/triage/[date].md.

Once you have the list, keep going: hand the deduplicated set to your issue tracker's MCP server and let it create or update the tickets. The brain reads, the MCP server writes.

14. Fix the docs your change just broke

You merged a real change. The code works, and every document describing the old behavior is now quietly wrong.

Use the Ask the Brain skill. I just shipped [change or PR link].

Find every doc, runbook, and help article in the workspace that describes the old behavior, internal or customer facing. For each, show me the section that is now wrong and a rewritten version that matches what ships now. Flag anything that needs a human decision rather than a wording fix.

Upload each rewrite as a new version of the original file.

Hook it to your post-merge routine and the cleanup happens while the context is still fresh. Because rewrites go back as new versions, you keep the old text and the audit trail of who changed what.

15. An incident brief in five minutes

The first half hour of an incident goes into remembering what shipped, whether this has fired before, where the runbook is, and who owns the service.

Use the Ask the Brain skill. Production issue: [paste the error, alert, or symptom].

From the workspace, pull: any past incident write up or postmortem describing the same or a similar symptom and how it was resolved, the relevant runbook and the current owner of this system, and any past decision or known limitation that might explain the behavior. From the repo, pull every change to the affected area in the last seven days with authors.

Then give me the three most likely causes ranked by the evidence behind each, the exact files to look at first, and what you are unsure about. Do not assert a root cause you cannot support from what you found.

The moment it is resolved, write the fix back as a short note in the incident folder. The next person who hits it, quite possibly you in six months, gets the answer handed over instead of repeating the dig.

16. The investor update, drafted from what actually happened

Every month you rebuild the update from memory and a dozen dashboards, stitching the numbers to the narrative the night before it is due.

Use the Ask the Brain skill. Draft our [monthly] investor update for [period], matching the format and voice of the last three in /board/updates/.

From the metrics exports, board docs, and project files in the workspace: the headline numbers and how they moved against last period and against plan. The three biggest wins with the evidence behind each. What slipped and why. Key hires, launches, and customer milestones. The current asks.

Lead with the numbers, stay honest about the misses, and flag anything where the data looks thin or I should double check before this goes out.

Drop the export from your analytics tool into the workspace before you run it and the numbers come from the actual file rather than a recollection. This is a draft, not a send. The opening paragraph is yours, because the read on where the company is going is the one thing the brain cannot have.

17. A full 360 on any project

Use the Ask the Brain skill. Give me a complete picture of [project].

The goal and why we are doing it, with the original decision doc or PRD. Current status: done, in flight, blocked. The timeline against the original plan and where it slipped. Who owns what. The risks and open questions nobody has resolved. Any customer or revenue impact tied to it. And if it has shipped, the early signals, good or bad.

End with one honest paragraph on whether this is on track, at risk, or off the rails, and what would have to change to fix it.

This is the one leadership runs after time off, or before stepping into a project that crosses three teams. It tells you where you are needed and who to talk to, which is usually the whole question.

18. The decision retrospective

Judging a call you made three quarters ago means reconstructing what you expected, when it actually shipped, and what happened next. The pieces are usually in three places.

Use the Ask the Brain skill. Run a retrospective on the major decisions we made over [the last 2 to 4 quarters].

Pull the decisions from our decision docs: pricing, packaging, onboarding, go to market, key features. For each one: what we changed, when it shipped, and what we expected it to do. Then line that up against the metrics exports in the workspace and tell me what actually happened afterward.

Give me your best read on whether each one helped, hurt, or did nothing, with the evidence. Say clearly where the correlation is too messy to call. Rank them from clearest win to clearest miss and flag the ones to double down on or reverse.

The output is only as good as the exports you park in the workspace, so drop them in first. The honest reads are the valuable ones, and the "too messy to call" line is what keeps the whole thing credible.

If that reads like a lot, it is. Do not try to run twenty workflows by Friday.

Pick the single thing that wasted the most of your time this week and set that one up. You will feel it the same day, and every workflow after it is easy because the setup is already done.

Three things worth knowing early.

The brain is only as good as what is in it. An hour spent importing the folders your work depends on pays for itself across every workflow above. Ten good documents beat ten thousand you never look at.

Write the output back, every time. It is the difference between a smart assistant and one that compounds. Today's synthesis is tomorrow's starting point, and next quarter it is the thing that answers the question before anyone asks.

Schedule the ones you repeat. Your orchestrator can run these on a cron or a hook, so the Monday triage and the Friday changelog are waiting when you sit down instead of being one more thing to remember.