Foundationby Foundry 41Made specifically for teams running onSlackGitHubGoogle Workspace
Governed workflow infrastructure. In your own AWS account.
The reusable operating layer beneath Foundry 41 delivery.
Foundation is the customer-controlled infrastructure we are building for prospective design-partner engagements, one cross-system workflow at a time. The Blueprint sets the systems, permissions, approvals, evidence, monitoring, and recovery that workflow actually needs.
Customer-controlled by design
Keep the environment, records, and operating choices.
The release runs in your AWS account; the agreed data-flow and external calls are documented for the workflow.
Agreed memory, work records, approvals, and outputs stay in your account under your key.
AWS, Slack, Google, model, API, and other providers bill you directly under your own relationships.
Foundry operates through delegated access you can revoke, or hands over the runbook. Software rights follow the agreed license.
Illustrative workflow components
Connect only what one workflow needs.
These examples show how approved systems can support bounded work in Slack. They are not a promise that every component is included in every deployment; the Blueprint defines the authoritative sources, permissions, approvals, and acceptance evidence.
Find the buyers, then write to them
“Find the economic development offices in New Hampshire and Maine, then draft an intro to each.”
It researches, deduplicates, and builds the candidate list as companies and contacts in your own CRM. It then prepares one Gmail draft per reviewed contact. A person verifies the source, suppression status, applicable rules, recipient, and exact message before any send.
CRM · Gmail drafting · Human review
The voyage of one request
Web search, CRM, Gmail. Each one a switch you turned on, each one bringing its own tools.
Companies, contacts and drafts, in DynamoDB and a mailbox you already own.
Slack messages, search queries, scoped task context for model inference, and Gmail draft fields. The Blueprint records the exact fields, providers, credentials, and retention; no reusable key should be sent to the model.
Remember what the company decided
“What did we agree about the Porto lease, and who owns the next step?”
It keeps memory per channel and per person, reads the meeting transcript, finds the thread where it was settled, and answers with the decision and the date. The record lives in your account, so it survives the person who wrote it leaving.
Memory · Transcripts · Documents
Run the week before you get in
“Every Monday at eight, tell me what is stuck and draft the chases.”
A routine you write in your own repository, or just ask for in Slack. It triages the inbox on a cadence you set, checks the pipeline, proposes demo slots from the team's free and busy, and posts what needs a human decision.
Routines · Calendar · Todos
Works in branches in your own GitHub org and opens a pull request for review.
An isolated browser session, only on the domains you allow.
Shared todos per channel, with a morning digest by DM.
Where the work actually happens
You stay in Slack until it is time to press send.
A real request crosses several systems, and it is fair to ask which window you are supposed to be looking at. Here is one, end to end: find contract manufacturers, produce a one-pager and mockups, and write five intros with the right attachments on them. You are in the channel for all of it except the last step.
Asking, reviewing and asking for changes all happen in the Slack thread you started. There is no console to log into.
The shortlist in your CRM, the one-pager in your Drive, the five messages in your Gmail drafts folder. Nothing lives in a tool you would have to cancel.
It writes the five and stops. You open Gmail, read them, change what you want and press send yourself, five times.
Map every boundary
Your account is the primary deployment boundary.
The teammate, agreed records, tables, and customer-managed keys run in your AWS account. A signed release enters; approved requests and the data needed to fulfill them leave for Slack, Google Workspace, the model provider, and any other scoped service. The Blueprint documents each data flow, field, credential path, retention rule, and provider boundary.
Reusable, not universal
Foundation brings a component library; each workflow enables only the systems and actions it needs.
Candidate components
Choose the smallest set the workflow requires.
These components are demonstrated, available, or under active development in Foundation's internal references. The Workflow Blueprint confirms current availability, credential boundary, permissions, and acceptance tests before any component enters a customer scope.
CRM
Companies and contacts in your own DynamoDB tables, bound to the channels you pick. No third-party CRM seat.
Bulk email on SES
Reserved for confirmed-opt-in newsletters or other customer-approved uses after applicable requirements, suppression handling, records, and human send authority are established. Not for cold outreach.
Gmail drafting and triage
Reads a company mailbox, drafts replies, and triages the inbox on a cadence you set. Sending stays with a person.
Calendar and availability
Each person's own calendar, by their own consent, plus team free and busy for finding a slot.
Google Drive
Read-only Drive access for admins, in the channels you configure.
GitHub
Short-lived tokens so git and gh work against your org's repos. It works in branches and opens pull requests.
Otter transcripts
Read-only meeting transcripts through a fixed proxy that alone holds the API key.
Knock
Read-only access to your Knock notification configuration through its remote server.
Read-only web
An isolated browser session that visits only the domains you allow. Per person, in direct messages.
Todos
Per-channel and per-person lists, with a morning digest delivered as a direct message.
Routines
Scheduled prompts. Write one in your config repo, or just ask for one in Slack.
Documents
Durable per-channel document storage in your own S3 bucket.
Memory
Scoped per channel or per person, encrypted with your key, in your account.
Upwork
Search Upwork and draft proposals. One goes out only after a person approves the exact draft.
Web search
Search from any channel or direct message, on the domains your config allows.
Why this initial stack
Fewer platform choices, clearer operating boundaries.
Foundation starts with AWS, Slack, and Google Workspace so each scoped workflow can have a reviewable deployment, permission set, and data path. Other systems are added only when the workflow requires them and their boundary can be verified.
Slack
One workspace, one app, one set of scopes generated from the capabilities you enabled. Your team already lives there.
AWS
One account to provision into. The CRM tables, the mail proxy, the schedules and the storage are real resources you can see and delete.
Google Workspace
One OAuth client. Mail, calendar, files and web sign-in all come from it.
One worked example
From a researched list to reviewed drafts.
The fictional record below illustrates a controlled outbound workflow; it is not a customer result. Before implementation, the Blueprint must establish the lawful basis, channel rules, suppression and consent requirements, data sources, approvals, and recordkeeping. Human review is a control, not a substitute for applicable law.
#growth · 9:14 AM
31 qualified · 6 flagged for a person · 3 duplicates merged. The source URL and the date are kept on every record.
Waiting on Maya. Nothing leaves the mailbox until she presses send.
Drawn from team free and busy. Proposed, not booked.
Back in the channel. Nothing sent, nothing booked.
How delivery works
Blueprint. Scope. Deploy. Validate.
Foundation is not a generic self-service install today. Foundry and the design partner first define one workflow, its systems, permissions, controls, acceptance cases, and recovery path; then a version-pinned release is deployed into the customer's AWS account.
Blueprint the boundary
Confirm authoritative sources, narrow permissions, credential handling, human approvals, retention, failure paths, and applicable requirements.
Deploy the agreed release
Install a reviewed, version-pinned Foundation release and workflow configuration into the customer's environment. Upgrades are explicit changes, not silent updates.
Validate and hand over
Replay agreed cases, measure the target outcome, document monitoring and recovery, then operate through revocable access or transfer the runbook.
Extend it yourself
Your teammate is configured in your own repository.
Skills teach it how your company works. Routines run scheduled prompts you write. Both live in your repo and go through your own review, so the people who know the work shape the work.
Wider triggers, and shipping your own capability packages beside the built-in ones, are coming.
What you control
Your environment, data, configuration, records, and operator.
Foundation's target boundary keeps reusable credentials in scoped proxies rather than with the model. Every customer scope verifies the actual credential path, allowed operations, approval points, and remaining exceptions before production use. Foundation and other software rights follow the agreed license.
- IInfrastructure
The AWS account and every resource the release creates. Version-pinned, so nothing changes under you.
- IIApps and credentials
Your GitHub App, Slack App, Google client, model subscription, and reusable secrets remain customer-controlled. Any Foundry operational access is delegated, revocable, and documented in the workflow scope.
- IIIConfiguration and knowledge
Your instance repository and your skills repository, in plain Git, reviewed by your people.
- IVRecords
Memory, logs, approvals and outputs stay in your account, encrypted with your key.
The words on the switches
Capability, tool, bundle, boundary.
These terms describe Foundation's current and planned control surfaces. The customer scope must still verify what is implemented, what is permitted, and where enforcement occurs.
A bounded group of tools, infrastructure, configuration, and permissions. Only capabilities required by the workflow enter its scope.
One function the model may call, with a defined input and result. A tool belongs to a capability and does not create permission by itself.
A client for one outside system. Its API surface, errors, permission path, and credential boundary must be verified for the customer scope.
The permissions granted for a related family of components. Each bundle should be narrowed to the selected workflow rather than the whole company.
The target boundary for reusable credentials and fixed external operations. Some internal components have reached this boundary and others remain product work; the Blueprint records the actual state before use.
A requested or scheduled unit of bounded work. The production direction adds resumable state, retries, disposition, cost, and recovery to the run record.
The customer-specific path from trigger to business disposition, including systems, state, approvals, exceptions, acceptance evidence, and recovery. Scheduled prompts exist today; event-driven and resumable orchestration remains product work.
A conversation with shared scope, memory, and bound capabilities. It is an entry point for work, not the complete workflow engine.
Versioned instructions the agent reads on demand. A skill can explain how to use a capability; it cannot grant access or replace enforcement.
One version-pinned Foundation deployment in a customer's environment. Its exact systems and permissions follow the agreed workflow scope.
A scheduled prompt written in configuration or requested in a channel. It is useful automation, but not a substitute for deterministic workflow state and recovery.
A planned extension boundary for customer-specific code. Availability and support must be confirmed rather than assumed.
Commercial terms
Scope the workflow before pricing the work.
Foundation pricing, license tiers, trial terms, and support levels are not yet published. A paid Workflow Blueprint establishes the systems, controls, delivery scope, customer operating costs, and implementation recommendation before Foundry proposes commercial terms. Cloud, model, API, and third-party providers remain direct customer relationships.
How it differs
Good tools, aimed at different things.
These products have different hosting and operating models. The comparison is directional, not a substitute for current vendor documentation or a workflow-specific security review. Foundation's relevant question is whether the scoped workflow can be deployed, governed, evaluated, and recovered in the customer's environment.
Claude Tag
- Runs
- A managed Anthropic service. No self-hosted option is offered.
- Credentials
- Inside that service, with your memory.
- Built in
- A very good general assistant, plus whatever an admin connects.
OpenClaw
- Runs
- On your own machine, state stored locally.
- Credentials
- On that machine. Hosted or local models.
- Built in
- Many channels and community skills. Broad on purpose.
Hermes
- Runs
- Your machine, or the Nous cloud.
- Credentials
- Wherever you run it.
- Built in
- Persistent memory and automation, pitched at an individual.
omp
- Runs
- A local coding agent in your terminal.
- Credentials
- Local.
- Built in
- Coding tools. Foundation uses it as a runtime and adds organization-specific deployment, controls, and capabilities.
Scoped to one workflow
- Runs
- In the customer's AWS account, from an agreed version-pinned release.
- Credentials
- Scoped proxies are the target boundary; the actual path is verified component by component.
- Components
- Selected context, tools, integrations, approvals, records, and schedules; current availability is confirmed in the Blueprint.
- Controls
- Customer-specific acceptance, monitoring, release, rollback, recovery, and handover requirements.
- Commercial terms
- Not yet published; provider usage is billed directly to the customer.
Internal reference deployments
Running internally. Customer evidence comes next.
Sky and Olivia run as Foundry 41 internal references in separate AWS accounts and Slack workspaces. They demonstrate selected interaction and control patterns; they are not customer deployments or proof of a customer outcome. A design partner starts with a paid Workflow Blueprint and one measurable workflow.