Prepare tomorrow's leadership brief. Compare the pipeline report with last week's decisions, then flag anything without an owner.
Company brains
An AI teammate in Slack, running in your own cloud.
A company brain is an AI teammate your team reaches in Slack. It runs in your cloud account with its own memory, skills and integrations, takes on bounded work, and hands anything consequential to a person for approval.
Last updated
In practice
What does working with a company brain look like?
Someone asks in a Slack thread. The teammate starts an isolated job with only the approved context, does the work, and posts the result back for review. Nothing changes in a business system until a person approves it.
# leadershipTEAM WORKSPACE · APPROVED MEMBERS
The coordination problem
Why not just give everyone an AI chatbot?
Because personal chat speeds up isolated tasks while scattering context, decisions, and outputs across private sessions. Foundry gives the company one governed way to delegate and review real work.
Before: everyone starts over
Operations, finance, and owners work from separate chats, document copies, and business systems. Context splinters and decisions disappear.
After: work moves together
One request, shared approved context, a named reviewer, and a visible outcome connected to the systems the company chooses.
Governed workflows
What is a governed AI workflow?
A governed AI workflow is one bounded piece of company work where an agent receives only the context and access the task needs, runs in an isolated job, and hands its output to a named person before anything consequential happens. Every run leaves a record the company keeps.
Foundation is the reusable infrastructure we are building beneath this work: security, permissions, connectors, approvals, memory, audit, release, failure handling, and evaluation. Each customer workflow still needs its own integration, acceptance evidence, monitoring, and recovery design, and the Workflow Blueprint states which parts are already verified.
01 · GOVERNED CONTEXT
Give the work the right context—not all the context.
Foundation selects skills, memory, configuration, and approved sources in a form the team can inspect. Each job receives only the relevant context and access.
- Editable operating knowledge
- Per-team memory and rules
- Approved connections to business systems
Company sources
Approved policies, team memory, system data, and a versioned workflow skill.
Selected job context
The task receives only the relevant context and access—not every available company source.
Bounded work
An isolated job completes the task and returns an output for a person to review.
02 · ISOLATED EXECUTION
Let agents work without giving them the keys to everything.
Each conversation gets a dedicated job environment. The agent receives bounded capabilities, performs the work, and reports back with an artifact or decision—not an invisible chain of autonomous actions.
- Scoped tools and credentials
- Separate execution environments
- Logs and outputs the company keeps
09:14:03REQUEST RECEIVED
09:14:04scope: referral-follow-up
09:14:04sources: playbook, payer-rules, practice-system/read
09:14:05ISOLATED JOB STARTED
09:17:4112 records checked · 8 drafts prepared · 3 missing items
09:17:441 EXCEPTION REQUIRES OWNER
OUTPUT SAVED · REVIEW BATCHNo external write-back performed.
03 · HUMAN CONTROL
Put people where judgment matters.
Rules decide what the agent may prepare. Named owners handle exceptions, approve consequential actions, and keep the reasoning with the work record.
- Explicit approval points
- Named workflow owners
- Reviewable actions and exceptions
41
Foundry agent needs a decisionREFERRAL FOLLOW-UP · EXCEPTION 01
Request updated authorization?
The file is complete except for an authorization date outside the approved rule. The draft is saved; the practice system has not been changed.
Company brains
What is a company brain, and who controls it?
A company brain is a persistent context layer—decisions, conventions, documents, and operating rules—that people and agents draw on, so work does not start from zero every session. We build it in your cloud account, under your keys, and scope what each job may read.
You pay model, cloud, API, and software providers directly; Foundry does not resell usage or mark up tokens. Foundry works through delegated access you can revoke, then operates the system or hands it over. Foundation and other software rights follow the agreed license.
Talk through the architecture- Deployment and workflows
Your installed environment, operating configuration, workflow definitions, and release records, subject to the agreed software license.
- Company context
Data, memory, configuration, and the rules that govern access.
- Credentials and accounts
Your provider relationships and secrets remain under your control.
- Work records and artifacts
Decisions, logs, files, and operational outputs stay with the company. Software rights, including code changes, follow the agreed license.
- The option to change operators
Revoke Foundry's role or use the runbook to operate the system yourself.
A concrete first workflow
What does a first workflow look like?
Something people already do every day. In this illustrative clinic example, a referral case moves from intake to preparation, one human decision, and a system outcome—not “chat with AI.” More healthcare workflows are on the healthcare page.
REFERRAL FOLLOW-UP · ILLUSTRATIVE
One owned case from request to outcome.
The agent prepares routine work. Staff see exceptions and approve action. The record keeps the context, draft, decision, and outcome together.
12FILES REVIEWED
8DRAFTS READY
3MISSING ITEMS
1STAFF DECISION
WORK RECORD · 041-0927OWNER · REFERRAL TEAM
01
Intake opens the case
COMPLETEApproved referral fields and source records enter one work record.
02
Agent prepares follow-up
COMPLETEPacket checked, missing information flagged, drafts saved.
03
Staff handles the exception
REVIEW REQUIREDA named owner reviews the one item outside the approved rule.
04
Approved outcome writes back
PENDINGOnly after approval; the work record retains the decision and output.
How a design-partner engagement works
How does an engagement work?
It starts with a short fit call and a paid, fixed-scope Workflow Blueprint. If the Blueprint confirms fit, the design-partner target is one governed workflow validated within 30 business days of Blueprint kickoff; then Foundry operates it or hands it over.
The Blueprint has standalone value even if we do not build. For an appropriately scoped engagement with access and integration readiness, each stage leaves a usable artifact in the partner’s environment. The 30-day window is a delivery target, not a general-availability promise.
Days 1–5
Workflow Blueprint
Map the cross-system workflow and exceptions, buyer-owned baseline and target, accountable owner, authoritative data, permissions, applicable requirements, autonomy and approvals, acceptance cases, failure handling, recovery, phased scope, and budget.
Days 6–20
Build
Prepare the agreed environment boundary, narrow integration scopes, governed context, and first workflow.
Days 21–30
Validate
Replay agreed cases, verify approval and failure paths, measure the target outcome, and document monitoring, release, rollback, recovery, and the operating backlog. These delivery controls are required even while the reusable product system matures.
After validation
Operate or hand over
Foundry operates the agreed scope, or transfers the runbook and operational control to the customer team.
PAID · FIXED SCOPE
Workflow Blueprint
Diagnose the workflow before committing to a build. The Blueprint stands on its own and becomes Days 1–5 if the design-partner implementation proceeds.
- Cross-system workflow, exceptions, and operating owner
- Buyer-owned baseline, target, and acceptance threshold
- Authoritative data, permissions, approvals, and applicable requirements
- Evaluation, failure handling, recovery, adoption, scope, and budget
DESIGN-PARTNER IMPLEMENTATION
Foundry Implementation
Build and validate one important workflow after the Blueprint confirms fit, without treating the reference implementation as a finished product.
- Agreed environment and narrow integration boundary
- Scoped context, permissions, and explicit autonomy
- One governed workflow with a reviewable run record
- Acceptance results, monitoring, rollback, recovery, and runbook
OPTIONAL OPERATIONS
Foundry Operate
Operate the agreed workflow under delegated, revocable access, or hand operational control to the customer team.
- Selected monitoring and reviewed changes
- Operating review and prioritized backlog
- Model performance and cost review
- Documented incidents and recovery actions
Built from working software
Is any of this running today?
Yes, inside our own companies. Sky is Foundry 41's own company brain: it works in Slack, runs in its own AWS account, opens pull requests in our repositories, runs scheduled routines, and reads its own logs. Olivia is the instance we run for GrowLab.
Both are internal reference deployments, not customer deployments. A messaging thread starts a job in a dedicated sandbox with controlled access to code and capabilities; selected outputs—memory, code changes, files, todos, and routines—can survive a session. Broader work identity and automatic resume remain architectural direction, not a production claim.
Questions
Frequently asked questions about company brains
What is a company brain?
A company brain is a persistent context layer of decisions, conventions, documents, and operating rules that people and agents draw on, so work does not start from zero every session. We build it as an AI teammate in Slack that runs in the client's cloud account and scope what each job may read.
Where does it run?
In your cloud account, under your keys. You pay cloud, model, and API providers directly, with no usage markup from Foundry 41. Foundry 41 works through delegated access you can revoke.
What can it do?
Our internal deployment, Sky, takes requests in Slack threads, opens pull requests in our repositories, runs scheduled routines and reads its own logs. For a client, the Workflow Blueprint sets which memory, skills, integrations and approvals it gets.
What is Foundation?
Foundation is the reusable infrastructure Foundry 41 is building beneath company brains and governed workflows: security, permissions, connectors, approvals, memory, audit, release, failure handling and evaluation. Maturity varies by component, and the Workflow Blueprint states what is verified for your deployment.
Does it act on its own?
Only within limits you set. Every consequential step has a documented autonomy level, and anything that writes to a business system waits for a named person's approval unless the workflow owner has explicitly approved a narrow automatic policy.
How long does the first workflow take?
For an appropriately scoped design partner with access and integration readiness in place, the target is one governed workflow validated within 30 business days of Workflow Blueprint kickoff. It is a target, not a promise.
Is Sky a customer deployment?
No. Sky is Foundry 41's own company brain and Olivia is the instance we run for GrowLab. They are internal reference deployments, not customer deployments or evidence of customer outcomes.
Bring one operational problem
Give important work an owned place to run.
A short fit call and focused discovery confirm whether the workflow merits a paid Workflow Blueprint, which maps the context, approvals, integrations and production path.