CompuBrain

Inspiration

Every company brain starts with retrieval: chunk, embed, search, prompt. The harder half is the asker. The same question from a new sales hire, the CFO, and an AI agent should produce three different correct answers, and one of them may be a refusal. Putting the role in the system prompt only discourages a leak. We wanted it to be impossible.

The second problem is who gets to extend the brain. The person who knows what it is missing is usually not the person who can build it.

The third is that knowing is not the same as moving. Work stalls between departments, where one team is waiting on another and nobody has asked.

What it does Answers by identity. One question, three askers, three answers. Sales gets the policy in plain words and the approver's name. The CFO gets the same policy plus the legal memo that contradicts it, the revenue treatment, and last quarter's exceptions. A support agent gets JSON it can relay to a customer, with no internal names. Refuses without knowing. Ask about compensation bands and the answer is "That's outside your scope." The model was never shown the document, so there is nothing to talk it into. Reports disagreement. When sources conflict, it says so and cites both. It does not pick one. Takes work in by email. Mail sent to the company inbox is pulled into the repo as documents, attachments included, and the brain acts on it. Acts on new data. For each new document it opens one GitHub issue per team, each written under that team's role: onboarding tasks with due dates for sales, and for leadership the things sales cannot see, such as a discount above the approver's limit or a refund window the playbook has wrong. Unblocks other departments by email. When a team's task is waiting on another department, the brain writes that department a request: what is needed, for which customer, by when. It sends it from its own inbox to the department's inbox. Each email is written only from what the receiving department is allowed to see, and says so when background was withheld. Forecasts choke points. From every planned task and every request between departments, it shows load by department and week, who is waiting on whom, and where work will jam first, with one action per jam. The forecast is gated like everything else. Asks for the tools it lacks. When a file arrives that it cannot read, it opens a tooling issue saying who is blocked, writes the request for a reader, and starts CERATA to build it. A person reviews and merges the pull request. The brain then goes back for the file. Answers in the workflow. Comment /brain ask as:maya … on any issue and the reply comes back through the same gate. Keeps a ledger. Every question and action: who asked, the role it ran as, what was cited, what was denied. One run, start to finish

During the hackathon we emailed the company inbox a signed contract amendment as an .rtf attachment, a format the brain had no reader for.

The mail loop pulled the email and the attachment into the repo. The brain planned the work in the email body: a sales issue, a leadership issue, two conflict issues. It could not open the attachment, so it opened "The brain cannot read .rtf files", wrote the consume command, and started CERATA. CERATA built an RTF reader with twelve tests. One was red, so it opened the pull request as a draft marked "do not merge". The red test turned out to be a bad test; we fixed it in review and merged. The brain went back, read the amendment in five sections, and opened the resulting issues. Leadership's first task was to confirm the amendment was genuine, because it came from a personal email address and not from a signatory at the customer. It also flagged that the contract value in the amendment disagreed with the order form, and emailed Legal and Engineering for what it needed from them. How we built it Snowflake holds the knowledge at three grains: chunks, per-document summaries, and topic digests. Every row carries one scope, set at ingest. Planned tasks and outgoing emails live in Snowflake too, behind the same policy. One row access policy gates every table. Each kind of asker is a Snowflake role, and a question runs on that role's own session. The application never passes a scope, so it cannot widen one. The policy binds the table owner too. Agents are principals. A support bot authenticates, gets a role and is filtered exactly like a person. Claude (Haiku 5.5 at ingest, Sonnet 5.5 for answers, action plans and the forecast narrative) reads only what the gate returns. GitHub Actions is the action surface: mail, intake, ask, and CERATA workflows. AgentMail gives the brain and its departments real inboxes, for mail in and unblock requests out. CERATA is our open-source GitHub Action for the people at the choke point. Someone, or here the brain itself, names a capability that is missing, and CERATA hunts an open-source implementation, checks its licence, metabolizes it into the repo with tests it actually runs, and opens a pull request for review. It refuses to call a red trial done. Tools added this way don't break when the vibe is over. FastAPI and a single page: the three-asker view, the flow panel, and the ledger. Challenges we ran into Summaries and digests leak. A summary of a mixed document carries restricted content past a chunk-level gate. We rebuilt both so each is made from one scope's material only. A disagreement between documents in different scopes is invisible to anyone who holds only one of them. Conflict detection had to move to answer time, over what the asker can actually retrieve. An email crosses a boundary an answer does not: the sender may know things the recipient may not. We write each email from the recipient's side of the gate. Today that filter runs in application code with the model doing the redaction, so it is weaker than the database gate on answers. GitHub will not let a bot's comment start another workflow. The brain's tool request is posted as a comment for the record and started by a workflow dispatch. Snowflake trial accounts block Cortex AI functions, so embeddings are computed outside and loaded in. Today they are lexical vectors with model-side query expansion; one setting switches to Cortex or Voyage. GitHub issues are visible to everyone on the repo, so an issue cannot yet be gated the way an answer is. Accomplishments that we're proud of The gate is tested against the live database: 69 assertions on what each role can and cannot reach, at every grain. An emailed attachment in an unreadable format ended as planned work, with a human needed only to review and merge the new tool. The brain questioned the sender of that email without being asked to. Four customer documents produced 22 unblock requests across five departments, 20 of them delivered to real inboxes, and a forecast that named Engineering, Product and Legal as the places work would jam. Two readers (Word and RTF) were added to the brain through CERATA during the event. What we learned

Scope has to be data, not a prompt. Once it is, answers, refusals, actions, emails, forecasts and the audit trail all fall out of the same rule.

An agent that says "I can't do this yet, here is what I need" is more useful than one that guesses.

What's next One Snowflake user per principal, and per-team issue trackers so issues are gated like answers. Move the recipient filter on emails into a database policy. Real capacity data. The weekly capacity per department is an illustrative number today, so the forecast is arithmetic over planned work, not a trained predictor. Let the brain choose its own candidate tools. Today it picks from a short fixed list per file type. Merge duplicate requests: two teams asking one department the same question should produce one email. Real embeddings.

Built with: Snowflake, Claude (Anthropic API), Python, FastAPI, GitHub Actions, AgentMail, CERATA

Built With

• agentmail
• cerata
• claude-(anthropic-api)
• fastapi
• github-actions
• python
• snowflake