Ask Your Org: A GitHub-Native Company Brain

Ask Your Org was a separate system built alongside REMI: a GitHub-native company brain designed to help employees and agents answer organizational questions without pretending that every document was equally current, authoritative, or safe to use.

The goal was not another chatbot over a folder of files. It was a routing-and-judgment layer for the business: what the company means by a term, where the canonical answer lives, which source wins when two sources disagree, who owns the decision, and when the system must stop and escalate.

The architecture

The blueprint separated organizational context by how quickly it changes:

Description — culture. How the assistant thinks, speaks, cites, asks for clarification, and respects hard rails. This changes on identity-time.
Files — structure. The company vocabulary, source map, people, ownership, and priorities that should be present in most conversations. This changes on org-time.
Connectors — operational reality. Live documents, conversations, tasks, CRM records, performance data, and assets. This changes in real time.

The operational test was simple: if it changes when tools, people, or priorities change, it belongs in a file. If it changes only when the company identity changes, it belongs in the description. If it changes as work progresses, it belongs behind a connector.

Under all three layers was the non-negotiable foundation: source-of-truth discipline. The system had to know where a category of information lived, how it was named, who owned it, and how a question should be routed there.

Conceptual knowledge flow

From operational reality to governed agent context

People and live systems contribute signals. The Company Brain resolves them against structure, provenance, and ownership before an agent answers or routes.

People & systems
Documents, decisions, work, metrics, and the humans responsible for them.
Company Brain
Canonical structure, source mapping, provenance, ownership, and permissions.
Governed agent
A source-aware answer, conflict warning, clarification, or human handoff.

Take the architecture with you

Get the public Ask Your Org Blueprint.

A 23-page reference architecture covering the three-layer model, five-file standard, source-of-truth discipline, connector audits, permission boundaries, and implementation scorecard.

Get the blueprint

Repository evidence

A company ontology people can inspect

The repository was structured as a navigable operating system, not an uncurated document dump. Sensitive source URLs have been removed from the public evidence.

GitHub company brain repository showing root folders for channels, company, knowledge, proposals, scripts, skills, styles, and system rules — **The organizational map**
The root taxonomy separated channels, company context, reusable knowledge, proposals, scripts, skills, styles, and system rules so agents could reason about location before retrieval.
Open full-size evidence →

The metadata visible in these pages was part of the architecture: type, status, provenance, source system, owner, and time. A page could point to Notion as the operational source rather than duplicating its contents and quietly becoming stale. GitHub supplied history, review, and inspectability; the source system retained operational ownership.

The five-file standard

Always-on context is expensive. Uploading everything makes retrieval less reliable and increases the chance that old or sensitive material gets treated as current truth. A file earned permanent context only if it was broadly useful, stable enough, compact, and structurally important.

The blueprint reduced that layer to five files:

Company One-Pager: business model, offers, scale, leadership, and the facts a new operator needs on day one.
Glossary: internal acronyms, framework names, product names, codenames, and terms the company uses differently from the market.
Source-of-Truth Map: recurring question type → canonical system, including tiebreakers where tools overlap.
People & Roles Directory: decision domain → durable role → current owner, so an answer can become a routed action.
Quarter Priorities: current objectives, measurable targets, team priorities, owner, and refresh date.

Everything else stayed in its natural system and was retrieved through permission-aware connectors. Full playbooks, fast-changing SOPs, sensitive contracts, salaries, and personal notes did not belong in always-on context.

Engineering decisions

Model authority, not just content

Constraint: A semantic search result can be relevant and still be wrong, stale, or non-canonical.
Decision: Attach status, provenance, source system, owner, and time to organizational knowledge, then encode which source wins for each question type.
Consequence: The system could surface disagreement and route to an owner instead of silently choosing the most convenient document.

Use pointers where reality already had a home

Constraint: Copying live business data into a knowledge repository would create immediate drift.
Decision: Let the GitHub page describe the policy and point to the operational source—such as Notion, ClickUp, Slack, or a CRM—for the current record.
Consequence: The repository became a map of company truth rather than a competing source of truth.

Make escalation a successful outcome

Constraint: Legal, financial, client-facing, HR, and ambiguous questions should not receive a plausible autonomous answer.
Decision: Encode hard rails, confidence gaps, named ownership, and a one-question clarification protocol in the assistant behavior layer.
Consequence: A safe answer could be a citation, a conflict warning, or a handoff to the right human—not forced completion.

Connectors as operational reality

The connector plan covered seven domains: documents and knowledge; communication and decisions; tasks and operations; customer and pipeline; performance and data; creative assets; and custom internal systems.

Connectors were not interchangeable search boxes. Each existed to answer a different class of question with the right permission and freshness. A process question might route to ClickUp, a strategic framework to Notion, a recent decision to Slack with owner confirmation, and a client commitment to a human rather than an interpretation.

That is how the system moved from retrieval to organizational judgment:

Interpret → locate → retrieve → judge → output

The forward-deployed part

The difficult work was not drawing the folder tree. It was getting people to decide what was actually canonical. Which system wins when Slack contradicts Notion? Who owns a policy after a role changes? Which source contains client commitments? What is confidential? How recent must a decision be before it requires confirmation?

Those are organizational conversations disguised as AI implementation. The company brain became useful only when employees and leaders confronted them directly.

Frontier direction: the decision layer

The next step was a custom decision ontology: representing recurring decisions as a trigger, evidence set, logic check, options, action, approval gate, and outcome metric. That would let the system capture not only what the organization knows, but how it makes repeatable judgments.

This layer remained exploratory. The knowledge architecture and repository structure are concrete; the generalized decision layer is a frontier direction, not a claim of a finished autonomous management system.

What this system proves

Ask Your Org shows a different part of enterprise agent engineering: institutional knowledge, governance, provenance, permissions, and human routing. Agents become more useful when the organization becomes legible to them—and the process of making it legible often improves the organization itself.

Public blueprint

Build the context layer before scaling the agents.

Use the blueprint to assess your current setup, then start a conversation if you want to map it onto a real organization.

Get the blueprint Start a conversation