Company Brain to Merger Brain

Inspiration

Company knowledge lives in Slack threads, Jira, docs, CRM and people's heads. Last month's Company Brain finalists showed that winning projects don't just search: they act on what they know and respect who may see what. We wanted a brain that notices when work drifts from the plan, tells the right people at the right moment, and proposes how to fix it. Then we asked the harder question: what happens to two company brains when one company acquires the other?

What it does

1. Company Brain (Northgate)

Hierarchy of memory: org → department → team → member. A member's private notes stay private until pushed to the team, like git push.
Top-down access: you see your own area and everything below it. Access to other teams or departments is requested and granted by the supervisor or the owning lead, expires, and is logged in a hash-chained audit log. Restricted data (pricing, pay) and private drafts never leak.
Ask: answers with a knowledge graph and citations checked against the source text. Questions outside your access are blocked, with the names of who can grant it.
Work: a timeline status bar, what was finished today, this week and last week (with summaries), and plans for tomorrow, this week and next week. Moving a task checks capacity, deadlines and dependencies, and Balance Load spreads work across days.
Conflicts, powered by Triggerware triggers: drift from SOPs, clashes between sibling teams (Identity v2 UUIDs break Billing), broken contracts between departments (an SSO slip breaks a Sales commitment), and pull request checks: every PR is mapped to the SOPs, policies, contracts and team plan, with each rule cited. Each conflict gets three resolution plans (one recommended, with owners and dates). The brain scans Slack and email to show who is already handling it, or offers a nudge. The board shows only conflicts at your level, below you, or from teams whose work affects yours.

2. Merger Brain (Northgate × Pulsepoint)

Day-0 assessment: 11 clashes across strategy, culture, policies, engineering, CRM and metrics, each quoting both companies' files. 5 look-alike rules are checked and correctly not flagged.
A one-year integration plan in phases: Before close → Q1 Stabilize → Q2 Align → Q3 Integrate → Q4 Fuse, with gate criteria for each quarter.
Plans down to team pairs (e.g. Platform ↔ Core, Billing ↔ Billing): a contract between the teams, how they work together, a culture-bridging habit, and joint tasks with one owner from each company every quarter.
Cross-company Ask and access: each person gets a mirror position in the other company, capped by the current phase. The owning side approves requests, and grants end at the next gate. A team lead sees only their own team's merger work and the partner team, and Ask only searches what the asker may see.
Tracking and negotiation: a Pulsepoint update ("we keep daily deploys") fires the Triggerware trigger plan_task_conflicts, breaks plan task T-07 and blocks the Q1 gate. The conflict goes to task owners, then department heads, then the integration lead. The chosen resolution writes plan v2 with a diff.
Fusion one unit at a time: a unit merges only when its checks pass. It gets a new ID, keeps the old IDs as aliases, and every item keeps a tag for its source company.

How we built it

Backend: Python with only the standard library: http.server and SQLite with FTS5 full-text search. Access filters run inside the SQL query before anything is searched, so no prompt can leak data.
Triggerware as the trigger layer: using the tw2-sdks Python client, the brain:
1. creates a Triggerware table brain_conflicts with tables.create(prompt=…), whose rows come from the brain's /api/triggerware/conflicts endpoint (every company and merger conflict);
2. registers five SQL triggers over it with triggers.create: drift_findings, clashes, contract_breaches, pr_checks and plan_task_conflicts;
3. subscribes with triggers.watch, so each delta Triggerware pushes becomes a notification to the right owners.

A local engine with the same added/removed delta semantics keeps the demo running offline, and every conflict card says which engine fired it.

Claude: optional, for writing answers. Without an API key, answers are extracted straight from the cited sources.
GitHub: PR checks accept GitHub pull_request webhooks, and resolved conflicts can open GitHub issues.
Frontend: a single HTML page in a black-and-white design. It works offline with example data, or live against the API.
Tests: 37 unit tests cover the access table, the scenarios, PR checks, merger access by phase, cross-company Ask, plan versions and fusion. We also verified the UI in headless Chromium.

Challenges

Keeping access checks in the database query, not the prompt, including cross-company access that changes by phase.
Deciding who negotiates a conflict: the lowest level that owns both sides, then escalating upward.
Merging two orgs without losing where knowledge came from: company-prefixed IDs, aliases, and fusion records in the audit log.
Turning conflicts into something Triggerware can watch: one table of conflict rows, and every reminder expressed as a SQL trigger over it.

What we learned

A company brain earns trust when it is right about who may know what, cites every claim, and turns findings into concrete, owned next steps. Merging two companies is the same problem at a larger scale, spread over time.

What's next

A full second company brain for Pulsepoint, so its people can ask questions too.
More Triggerware triggers: gate readiness, unit fusion readiness, and cross-company grants expiring.
Real Slack, Jira and CRM connectors.
Trimming the merger data on the server for each person.