Company Brain Company

A company brain is a layer over your CRM, help desk, finance system, documents and call notes that lets anyone ask a question in plain English and get an answer with its sources attached. Access rules stay in place; people see what they are permitted to see. The brain works with your existing hosting and permissions. You choose from two approaches: centralise records in a warehouse or retrieve them from source systems. Paloren agrees the architecture with your technical team before the build.

• Permission-aware answers
• Structured records and approved documents
• Architecture agreed before build

A company brain pulls from structured records that support joins and calculations, plus approved documents and SOPs. Paloren agrees which sources and which fields before building anything. The connection design also covers identity, freshness and deletion. If data is stale or deleted, the team sees that status instead of an old answer. This is what makes the brain reliable enough for everyday work rather than a demo that breaks when a source changes.

• Structured records and documents
• Identity and access mapping
• Freshness and deletion status

Paloren runs at least four evaluation cases covering correctness, isolation, recovery and evidence before release. All required cases must pass before the brain goes live. Changes to sources, questions, access rules or definitions trigger re-testing of those cases. The evaluation also shows what happens when records conflict or are missing. This gives the team a shared standard for what a good answer looks like, which is essential before the brain becomes part of ordinary work.

• Correctness and isolation cases
• Recovery and evidence checks
• Re-testing after changes

Paloren scopes company brain programmes at USD 60k to 150k over 8 to 12 weeks depending on sources and permissions. The first release focuses on a bounded answer path rather than a warehouse that tries to hold everything. That keeps the build manageable and the evaluation meaningful. Support, monitoring and handover are quoted separately, and the operating model documents who monitors, who approves changes and who receives alerts.

• First release with bounded answer path
• Evaluation and handover included
• Support quoted separately

Paloren is co-founded by Aaron Agius and Alex Agius. Aaron founded Louder, a growth agency, and has spent 15 years building marketing, data and growth systems. The people behind Paloren have spent two decades inside businesses such as IBM, Ford, LG, Unilever, Jaguar and Chelsea FC. That experience matters because a company brain needs commercial judgement as well as engineering. Paloren also trains teams, so the brain is adopted rather than abandoned after launch.

• Strategy through delivery
• Two decades of operating experience
• Training and adoption built in

A source contract records which system provides the data, which fields are needed, how identity is resolved across systems, and how the system knows when the data is fresh or stale. Paloren agrees this with your technical team before building the answer path. Identity resolution is the hardest part: the same customer may appear in the CRM, the help desk and the billing system under different identifiers. Getting this right prevents the brain from silently joining the wrong records. The contract also names the source owner, so changes can be agreed before they affect the answer.

• Sources and field contracts
• Identity resolution across systems
• Freshness and staleness signals

Permissions are inherited from the source systems, not rebuilt from scratch. A user sees what they are permitted to see in the CRM, the help desk or the document store. The brain checks both the account boundary and the source permission before returning any content. This prevents the common failure where a connected system accidentally exposes records the user should not see. Paloren tests this with restricted-user cases before launch, and re-tests when permissions change.

• Inherited from source systems
• Account and source permission checked
• Restricted-user testing before launch

The brain works best with approved documents that are current and relevant to the questions the team asks. Old versions, drafts and unrelated material add noise and reduce confidence. Paloren helps you agree which document types belong in scope and how they are kept current. Approved policies, SOPs, product sheets and service guidance are good candidates. Meeting notes and call summaries are useful when they are already recorded and permissioned. The brain should not become a dumping ground for everything.

• Approved and current documents
• Relevant to the questions asked
• Kept current with agreed ownership

Use this checklist before choosing a company brain provider. First, the proposal names the sources and fields in scope. Second, it defines identity resolution and freshness. Third, it confirms permission handling and restricted-user testing. Fourth, it includes evaluation cases before release. Fifth, it includes training and handover. Sixth, it states the support model and what is excluded. If any of these are missing, ask for written clarification before signing.

• Sources and fields named
• Identity, freshness and permissions
• Evaluation, training and support included

When a source changes, such as a new field, a renamed record or a different API version, the evaluation cases are re-run before the change goes live. This keeps the brain reliable rather than assuming it still works. Paloren documents the change process as part of the operating model: who is notified, who approves the change and who confirms the evaluation passed. This is more useful than discovering the change when someone notices the answers are wrong.

• Evaluation cases re-run after source changes
• Documented change approval process
• Named owner for each source

A data warehouse centralises records for analysis. A company brain lets people ask questions in plain English and get answers with their sources attached. You may use both: the warehouse stores the data, and the brain interprets it for the team. Paloren can connect to an existing warehouse or build a bounded answer path directly from source systems. The choice depends on the workflow, the data volumes and the questions the team needs answered.

• Warehouse: centralise records for analysis
• Brain: ask questions, get answers with sources
• Choice depends on the workflow and questions

The brain tracks when each source last updated successfully. If data is stale or a feed has failed, the team sees that status rather than an old answer. Paloren also defines who is responsible for keeping each source current, so ownership is clear. Documents need an owner and a review date, just as structured records do. This is part of the operating model rather than something the brain can solve on its own.

• Freshness signals for each source
• Stale or failed feed shown to users
• Named owner and review date for documents

Use this checklist before choosing a company brain provider. First, the proposal names the sources and fields in scope. Second, it defines identity resolution and freshness. Third, it confirms permission handling and restricted-user testing. Fourth, it includes evaluation cases before release. Fifth, it includes training and handover. Sixth, it states the support model and what is excluded. If any of these are missing, ask for written clarification before signing.

• Sources, fields and identity resolution
• Permissions and restricted-user testing
• Evaluation, training and support included