# Cortexes and access

> Many cortexes, who can read one, and how sharing actually works.

Source: https://mitosislabs.ai/developers/concepts/cortexes-and-access

You can have as many cortexes as you have offices. Each one is a separate graph
with a separate set of people who can read it. This page is about where that line
sits, because a memory product is only as useful as its boundaries are
believable.

## One office, one graph, one boundary

Each office runs its own namespace, its own database and its own pods. There is
no cross-tenant query path. A cortex is an isolation boundary, not a filtered
view of a shared store.

Every memory call takes the office id explicitly, which is the same boundary
showing up in the API:

```ts
const cortex = client.cortex(officeId);
await cortex.answer(officeId, { query: 'what did pricing move to?' });
```

## Adding people

People reach a cortex through the office. They are added by membership and by
invites, and access is granted at the office level: a member of the office can
read that office's memory.

There is no per-source or per-node sharing inside a cortex. If two groups of
people should not see the same material, that is two cortexes, not one cortex
with two audiences.

## Sharing a cortex publicly

A cortex can additionally be made publicly readable through a share link. Two
things to know about it:

<Steps>
  <Step title="It is off by default">
    Nothing is public until someone turns it on for that office.
  </Step>
  <Step title="It is read-only">
    A share link is a view. It does not grant writes, and it does not make the
    holder a member of the office.
  </Step>
</Steps>

## Agents

Agents live in an office and read its cortex. Their credentials are scoped per
integration, so an agent that needs Drive does not thereby get the mailbox. See
[integrations](/developers/sdk/integrations) for enabling one for a specific agent, and
[authentication](/developers/authentication) for how a credential is issued in the first
place.

## There is no cross-cortex query

<Warning>
  There is no cortex-to-cortex linking, no federation, and no cross-cortex query.
  Data does not flow between cortexes.
</Warning>

If you need results from two cortexes, your code queries each one and combines
the results itself. There is no server-side join, and a `universal_id` from one
cortex means nothing in another.

The practical shape this pushes you towards: one cortex per team whose knowledge
genuinely is shared, rather than one giant cortex per company that everybody
squints at.

## Where to go next

<CardGroup cols={2}>
  <Card title="Offices and agents" href="/developers/sdk/offices-and-agents">
    Create an office, hire agents into it, and manage their lifecycle.
  </Card>
  <Card title="Connecting sources" href="/developers/memory/sources">
    What a user can connect to a cortex, and how to hand them a link that does
    it.
  </Card>
</CardGroup>