# ARCA — the console guide > You are a person, and this is your guide. It takes you by the hand from > the login screen through every section of the console: what it is for, > what you see, what you can do with it. You need to know nothing about > ARCA to start: it's all in here. Just want to **connect an AI agent** (a > software assistant like Claude or ChatGPT) the fastest way? Its own > guide is right here, **"Connect your agent via MCP"**: this one instead > is for you, the human using the site. ## What ARCA is, in one minute ARCA is the **living memory** of your knowledge. Picture an archive of documents — notes, client cards, procedures, price lists — where nothing is ever lost: every change stays recorded forever. It is meant to be used **together with an AI assistant**: you steer, it does the heavy lifting (we'll come back to this). Five ideas are enough to get it: - **Documents organized by path.** Like folders and files on a computer: `clienti/acme.md` is the file `acme.md` inside the `clienti` folder. Every document is written in **markdown**: plain text with a little formatting (headings, lists, bold). - **Several independent memories.** ARCA can hold **several memories**: a *memory* is a self-contained knowledge space — its own documents, history, and settings. You work in **one memory at a time** and pick it top-left. (In this guide's figures the memory is called `centro`.) - **Every change is an event.** When someone writes — you from the console, or an AI agent — it isn't just an overwrite: an event is recorded with **who** wrote it, **what**, and **why**. What you see today is the sum of all past events. You can always rewind the history and see how a document looked yesterday. - **Nothing is truly deleted.** Even when you delete something, it stays in the history and can be recovered. Documents that aren't deleted are called **"live"** — a word you'll meet in the console. It's a permanent safety net. - **You steer, the agent operates.** This is the *helm* model. An **AI agent** is a software assistant (Claude or ChatGPT, for example) that *you* connect to ARCA so it works in the memory on your behalf. The split is clean: you, the human, **correct the text** of documents and leave **post-its** for the agent; the **structural** work — creating, moving, renaming, deleting, organizing folders — is the **agent's**. You hold the helm and set the course; the agent handles the maneuvers. (This is why, until you connect an agent, a new memory can look almost empty: there's no "add document" button, because the connected agent creates the documents. How to connect an agent is in the **Tokens** tab.) There's also a second door besides this console: the one for **AI agents**. They don't do the human login: they either **connect via OAuth** through a **connector** — the **MCP** hookup, the standard way AI assistants attach to external tools like ARCA; you just do a Google login, nothing to paste — or use a **key** (called a *token*) for *headless* agents (which run on their own, with no interface). You enter the console with Google or GitHub; the agent comes through its own door. More on this in the **Tokens** tab. Ready. Let's go screen by screen, in the order you meet them. --- ## 1. Logging in **What it's for.** It's the front door: the first screen you see. Its only job is to let you in. ARCA handles no passwords: it signs you in through Google or GitHub, the accounts you already use. ![The login screen](/guide/en/login.png) **What you see.** A centered card with the **ARCA** name and, below it, a one-liner that changes on each visit (just a touch of color — ignore it). Then the two ways in: - **Log in with Google** and **Log in with GitHub** — pick whichever you prefer. They take you to the *provider*'s page (i.e. Google or GitHub, the service you sign in with); once authorized, you land back in the console, already authenticated. - At the bottom, a dropdown for the **language** (Italiano / English). The choice is remembered in this browser. **In practice.** Click your provider, authorize, and you're in. A useful note: a new person's **first login** arrives "pending" — you'll be able to see the console only after an administrator has enabled you (a message on this same screen tells you). That's normal, not an error: it's how access is authorized. Once enabled, if you have no memory yet you land on a **welcome screen**: from there you create your **first memory** with the same wizard as the Memories tab (chapter 9), and become its *owner*. --- ## 2. Getting your bearings: the sidebar **What it's for.** It's the left-hand column, always present. It's your compass: it tells you **who you are**, **which memory you're working in**, and lets you move between sections. There is no top menu — it all lives here. ![The sidebar with the memory selector open](/guide/en/sidebar.png) **What you see**, top to bottom: - **ARCA** — the product name. Next to it, an arrow to **collapse** the bar to a thin icons-only strip (handy on small screens) and reopen it. - **Your identity** — the name or email you logged in with, and below it your **system role**: it decides what you can administer in the console. Which roles exist and what they mean is explained in the **Admin** tab (chapter 11), where they're managed. - **The memory selector** — the dropdown with the current memory's name (`centro` in the figure). Opening it, you choose which **memory** to work in: switching reloads every section onto that space. It only appears if you have access to more than one memory. The memory with the **crown** is the *system memory* (it holds the product's factory materials: normally you don't need to touch it). - **The sections** — Dashboard, Documents, Boot, Coherence, Tokens, Memories, Team, Guides and — admins only — Admin. Click to move around. It is the menu we will use in the next chapters. - **At the bottom**, your avatar: clicking it opens a menu with the **language** and the **sign out** button. Below that, the © TheLoop signature. **In practice.** First thing every time you enter: check at the top that you're in the **right memory** (the selector). Everything you see and write applies to that memory and only that one. **The console sea.** The waves in the background are still. When faint signals run along them, something is being written to the memory right now: you, another member, or a connected agent. Once the writing stops, the signals fade and only the waves remain. --- ## 3. Dashboard — the overview **What it's for.** It's the memory's overview: how big it is, how active, what happened recently. It's the first section that opens and gives you a sense of things at a glance, without opening anything. Nothing is edited here: you just look. ![The Dashboard with numbers and recent activity](/guide/en/dashboard.png) **What you see.** At the top, four **key-number tiles**: - **Documents** — how many live (non-deleted) documents there are now. - **Events written** — how many changes in total (remember: every change is an event). - **Writes, last 7 days** — how much work happened in the past week. - **Last write** — how long ago something happened. Below, two simple charts: **Events per day** (the columns of the last 14 days: you can see at a glance when the memory was busiest) and **Documents by type** (how many documents of each type). At the bottom, the **Recent activity** table: the list of the latest changes, one per row, with **when**, **which document**, **which operation** (create, edit, delete… — some labels and buttons are in English, as shown on screen), **who** did it, and the **version** reached. Changes made together, with a single motivation, appear grouped into one row with the *changeset* icon (a group of changes with a single "why" — we come back to this in the staging chapter): click it to expand and see the group's individual changes. **In practice.** Use the Dashboard as the memory's "pulse": open it, glance at recent activity to see what changed since last time, then head where you need to go. --- ## 4. Documents — the heart **What it's for.** This is where the knowledge itself lives: the document tree on the left, the open document on the right. Here you **read**, **correct the text**, and **star** what matters. It's the screen you'll use most. ![The document tree and a document open for reading](/guide/en/documenti-lettore.png) **What you see — on the left, the tree.** The list of folders and files, like a file manager. At the top a **search box** to filter by name, a filter **by type**, and the **star ★** filter (shows only the "always-on" documents — see below). Each row has a small **icon marking its type** (there are 7 types, explained shortly) and, on hover, a **star** to mark it. Click a file to open it on the right. If a memory is new or nearly empty that's normal: the connected agent creates the documents, not you — with one exception, the **post-it** (the only document you create; below). **What you see — on the right, the document.** At the top its **header**: the type, the path (`clienti/acme.md`), the version and how long ago it was updated, and a row of controls: - **The eye / code toggle** — switches from the **readable** view (the formatted markdown, as in the figure) to the **code** (the raw text, without the formatting applied). - **The star ★** — marks the document as *always-on*. - **The clock** — the document's **history** (more on this just below). - **The post-it** — attach a **note** for the agent on this document. - **Edit** — open the editor to correct the text (next chapter). Just below is the document's **description** (one line: "what is this object"), which you can correct with the pencil: it's a small change of its own — it asks for its own short motivation and saves immediately, without going through the staging of the next chapter. At the bottom of the page is **Live documents pointing here**: which documents, in the memory, refer to this one (the links between documents). **A document's history (the clock).** It's one of the most useful things in ARCA, because nothing is lost. Clicking the clock opens the history: **every version** of the document, **who** wrote it, **when**, and **what changed**. From there you can compare two versions and, if needed, **go back in time** by restoring an earlier one (even a deleted document can be recovered this way). It's the safety net we mentioned at the start, made concrete. **Two important concepts you meet here:** - **The star ★ (always-on).** Starring a document means saying "this is essential": it's the group of documents — the **always-on** set — that an AI agent loads **first** every time it starts, so it immediately knows how to behave. The star isn't a personal display preference: it lives in the document's data. You can star a **whole folder** too (it applies to all its content). The ★ filter at the top of the tree shows only this group. (You'll see the same concept called the "boot set": it is the same thing.) You govern this group's **order** and **weight** from the **Boot** tab. - **The 7 document types.** Every document has a type, with its icon: **Document** (text you consult), **Prompt** (instructions the agent *executes* — rules, procedures, identities: not just to read, but to act on), **Index** (a map that updates itself), **Ledger** (a chronological log), **Post-it** (your notes to the agent), **Folder**, and **Other**. Types are managed by the software, not created from the console. On some (Index, Folder) you read and attach post-its, but the content is written by the agent. The **full glossary** with icons is in the **Guide** tab, section **Type glossary**. **Leaving a post-it.** Post-its are your channel to the agent: you leave it an instruction attached to a document or a folder (e.g. "double-check this contact"). To create one, click the **post-it** icon (on the document header, or by hovering over a file or folder in the tree), write the note, and confirm. The agent will read it attached to that object and, once handled, detach it. A post-it is, to all effects, a document of type **Post-it**. **In practice.** On this screen you can: **open** a file from the tree, switch between **readable and code**, **star** what matters, open the **history** with the clock, leave a **post-it**, and **correct the text** with Edit (next chapter). The helm model always holds: you correct the text, the agent does the structure. --- ## 5. Editing a document (and the staging bar) **What it's for.** Correcting a document's text without risking overwriting others' work, and sending several corrections together with a single explanation. (It isn't a separate sidebar tab: you reach it from the **Edit** button inside Documents.) ![The editor open on a document](/guide/en/documenti-modifica.png) **What happens when you press Edit.** The document becomes an editable text area. Correct whatever you want. You aren't asked for a motivation right away: at the bottom you find two buttons, **Cancel** and **Stage**. "Staging" means: **set this correction aside**, don't save it yet. It's like a **cart**. You can correct several documents, stage them all, and send them together. ![The staging bar at the bottom, with the set-aside version](/guide/en/staging.png) **The staging bar.** As soon as you stage something, a **bar appears at the bottom** — present in every section as long as you have pending corrections. It contains: - **Staged corrections: N** — how many you've set aside. Clicking opens the list, where you can drop a single correction. - **The motivation field** — here you write **one single explanation** for all the corrections in the group. Required, at least 3 characters. - **Discard all** — throws everything away (immediately, no confirmation). - **Push (N)** — sends all corrections at once, with that motivation. When you press it, **a changeset** is created: the group of changes with a single "why", which you then find grouped in the Dashboard. Meanwhile, in the open document, a yellow strip reminds you that you're viewing the **set-aside version** ("leaves with the next push"): you can discard it from there. **Why all this?** For two reasons. First: the **motivation written once** covers the whole group, instead of repeating it on every line. Second, and more important: **overwrite protection**. If someone else changed that document in the meantime, your submission doesn't silently overwrite it: it warns you of the conflict and makes you restart from the updated version. You never lose anyone's work. **In practice.** Correct → *Stage* → (repeat on other documents if you want) → write **one** motivation in the bar → **Push**. Done: your corrections are in the memory, tracked with who/what/why. --- ## 6. Boot — what the agent loads, and in what order **What it's for.** The **boot** is the package of always-on documents (the starred ★ ones) that every agent receives **at every startup** (after connecting — how to connect: **Tokens** tab, ch. 8), before anything else. The agent doesn't assemble it: the **server** composes it, always in the same order — so every session starts from the same identical base. This tab shows that package for what it is — a **sequence with a weight** — and lets you govern it. ![The Boot tab with the weight dashboard and the sortable list](/guide/en/boot.png) **The dashboard at the top.** Three numbers — how many **documents**, how many **characters**, and roughly how many **tokens** (here = the unit AI models "measure" text in, not the *token*-key of the Tokens tab; the estimate is characters ÷ 3.3, calibrated on a real memory's prose). Below, the **weight bar** with four bands: - **green** (up to ~25k tokens) — the boot fits the limit many MCP clients apply by default to a tool's output: it reaches the agent whole, with no configuration to touch; - **yellow** (up to ~50k) — above that limit: the agent's client needs a higher ceiling, or the boot arrives cut; - **orange** (up to ~75k) — heavy: a sizable slice of the model's context window (its working memory) is gone before the conversation even starts; - **red** (beyond) — very heavy: every conversation starts burdened. The thresholds are indicative (they shift with models and clients, and will be tuned over time): the bar exists to make the weight **visible**, not to grade you. The ⓘ icon next to the title opens this same explanation in short form. **The list: the order is yours.** Documents appear in the **actual order** the agent will receive them. Drag the **handle** on the left of a row (or use the arrow keys with the handle focused) to move it: put first what the agent must read first — typically identity and rules, then the rest. Each row shows characters, ~tokens and **% of boot**: at a glance you see what really weighs. The star on the row removes a document from the boot (it asks for a **second tap** to confirm); to add one, star documents from the tree in the **Documents** tab — stars live there, the sequence lives here. **Saving the order.** As soon as you move something, the **"Order changed"** bar appears with **Cancel** and **Save order**. Saving writes the new positions **in one stroke**, as a single changeset signed by you — you'll find it in the Dashboard. If someone starred or removed documents in the meantime, the save doesn't go through halfway: it asks you to reload and redo — never a half-written order. **Post-its at the tail.** Your starred post-its appear in a separate box: they travel **after** the boot documents, marked as the operator's voice, and have no position to choose. **The composed boot.** At the bottom, the **"The composed boot"** box: **Show** displays the exact text — byte for byte — the agent will receive, in the order you chose; **Copy** puts it on your clipboard (handy for trying it in a chat). It isn't a reconstruction: it's generated by the same code that serves the agents, so it cannot drift. **In practice.** Star what's essential from the tree → open **Boot** → drag until the order tells the right story → keep an eye on the bar (green = relax) → **Save order**. --- ## 7. Coherence — the memory's traffic light **What it's for.** It's the dashboard of the memory's **quality**: it tells you whether the accumulated knowledge needs a review — a **coherence pass**, the periodic check the agent performs (the one you connect from the **Tokens** tab, ch. 8) — and it keeps the records of the reviews already done. Nothing is pressed here: you read the traffic light and, when needed, ask your agent for the pass in chat. The tab has **two faces**, and the pills at the top switch between them: **Pass** — the traffic light and the records of the reviews — and **Graph** — the map of the links between documents, as they are right now. **What you see.** At the top, the **health traffic light**: - **Green** — all in order: little has been written since the last pass. - **Amber** — a fair amount of unreviewed work has piled up, or a delivered report is still waiting to be discussed, or the memory has never had a pass. - **Red** — the backlog is large: a pass is truly overdue. The traffic light moves with the **volume of writing**: it counts the **events** accumulated since the last pass, never the calendar. An idle memory stays green even for months — there is nothing to review in what hasn't changed; "last pass N days ago" appears as information, not as the criterion. When the light isn't green, a dot also appears on the **Coherence** entry in the sidebar. Below, the **number tiles**: the outcomes of the last pass split by degree of autonomy (how many fixes the agent applied on its own, how many await your confirmation, how many are up for discussion), the passes delivered and still to close, and a few trend numbers on the network of links between documents — for example the **orphans**: documents no navigation path reaches. At the bottom, the **history of passes**: one row per review, with date, who launched it, status, and the fixes counted by degree of autonomy. Clicking a row opens the **report**: the record written by the agent — what it checked, what it fixed on its own (with the number of the *changeset* of the fixes, which you can find grouped in the Dashboard), what it proposes to confirm or to discuss. It's the reading that prepares the conversation. **The Graph face.** The second pill opens the memory's **map**: the same perimeter, the same thresholds and the same formula as the pass, but read **right now** — not the photograph of the last pass. The numbers at the top come in three groups: **size** (nodes, edges, average degree), **structure** (components, communities, density) and **health** (orphans, isolated documents, doors). Below them the map itself, and under the map a few short lists — the load-bearing documents, the orphans, the split candidates, the mixed communities. Every row of those lists lights the document up on the map, and the little arrow opens it in **Documents**. A **node** is a document. Post-its and ledger entries stay out of the graph by design: they are your voice and the chronicle of the work, not knowledge to navigate. An **edge** is a citation from one document to another, **plus** the edges every *view* (the **Index** documents, ch. 4) projects towards its members. Switch **View edges** off and only the citations remain: what you are left looking at is how much the knowledge cites itself, with the navigation scaffolding taken away. The **doors** are where an agent's discovery begins: the always-on ★ documents plus everything a live view projects. A document is an **orphan** when no door reaches it by following the edges — it exists, it may be written beautifully, and no agent will ever get there by navigating. The coloured patches are the **communities**: clusters of documents that cite one another more than they cite the rest. When one of them is spread across three or more top-level areas it also turns up in the mixed communities list — documents that talk to each other but live apart. The map is made to be handled: **drag** to pan, wheel or pinch to **zoom**, *Fit to screen* to get everything back inside. The labels have three states — none, the key ones, all — and the search box highlights what matches. **Double-click** a node to isolate its neighbourhood and read one story at a time; *Whole graph* brings you back. On a very large memory the numbers stay live while the drawing is not delivered: a cap declared out loud, never a silent one. Here too **you only observe**: nothing on this map writes. Clicking a node opens its details — who cites it, where it points, which community it belongs to — and **Open in Documents** takes you to the document itself, in the tab where reading and editing live. **Why there are no action buttons.** It's the helm model: the pass is launched and closed by the **agent**, and the discussion of the report — the review's "second tempo" — happens **in chat** with it, not here. This tab is the dashboard, not the lever. **And no automatic reminders.** ARCA schedules nothing on your behalf: the memory itself tells you when it needs a review — with the traffic light here, and with the same signal the agent sees on every boot (it will often be the one proposing the pass). All you have to do is say yes. **In practice.** The agent runs the pass and delivers the report; you read it here, discuss it in chat, and the agent closes the pass. --- ## 8. Tokens — letting an agent in **What it's for.** An AI agent doesn't enter with a login: it enters with a **key** (token) — or it **connects on its own via OAuth**, the way Claude and ChatGPT do with the connector. In this tab you see and govern *both* doors: the keys you mint and the ones born from connections. > **Just want to connect Claude or ChatGPT?** The simplest way — step by > step, no keys — is in the sibling section **"Connect your agent via > MCP"** (right here, in the Guide tab). This tab is for *seeing and > governing* the keys: the OAuth connections and the API keys for > *headless* agents. ![The Tokens tab with the create form and the list of keys](/guide/en/token.png) **Two kinds of key.** In the list, next to its name, every key carries a label: - **API** — the classic key, minted here: a secret you copy and paste into the agent (`Authorization: Bearer …` against `https://app.arca-memory.com/v1`). For headless agents, scripts, integrations. - **MCP** — the "shadow" key of an OAuth connection: it is born *on its own* the first time a person connects an agent through the connector, and its name is their email. There is no secret to copy — the secret is the Google login. That's why it **cannot be rotated** (the console blocks it): at most you **revoke** it, and on the next connection it is reborn clean, with the home memory only. **Creating an API key.** At the top you find the **form to create a key**: - A field for the key's **name** (e.g. "claude-code": one per agent or per use). - The choice of **which memories** the key can open (shown as checkboxes) and, for each, its **level** on that memory: **Member** (the agent can read and write) or **Admin** (it can also administer *that* memory). Note: this is the *key's* power over a memory — a different thing from a person's system role and from their *membership* (a person's access to a memory, chapter 11). One of the memories is the **home**: the *key's* default, used when the agent doesn't name another one (not to be confused with the installation's "default memory", chapter 9). - An honest recap — "This key will open: …" — of what you're about to create. - The **New token** button. Below, the **My tokens** table: name and label (API/MCP), the **memories** each key opens (tags, with a little house on the home), when it was created, and the **actions**: **Memories** (the sliders: curate which memories it opens), **rotate** (API keys only: new secret, the old one dies) and **revoke** (switches it off). If you're an admin, you also see a second table with the whole memory's keys. **Curating a key's memories.** The **Memories** action opens a window with the key's memories: tick to add, untick to remove, change the role next to each. The rules of the game: - **at least one always remains** — the last one on cannot be switched off; - if you remove the **home**, the key **moves its reference memory on its own** (to the default memory if granted, else to the first one left); - you grant only within your **mandate**: an *owner* of a memory can grant Admin or Member, a *member* grants Member; - for **MCP** keys there is also the owner's **membership ceiling**: the first connection grants *the home only* — the rest you add from here — and revoking a membership **removes that access** from the key on its own, at its next call. So, to add a *new* memory to an MCP key: first the membership to the person (chapter 11), then the tick here. *(Screenshot of the window coming soon.)* ### Connecting Claude or ChatGPT (no key: OAuth) It's the simplest door — no secrets to copy, the agent configures itself and the person does a normal Google login. The steps, per client, are in the sibling section **"Connect your agent via MCP"** (Guide tab, right here): in short connector URL `https://mcp.arca-memory.com/mcp` → **ARCA consent** → **Google login**. What stays below concerns *this* tab: who enters what they see, and curating the keys. **Who enters, what they see.** The identity is the **verified Google email** of whoever connects: every write carries that signature in the history. Consent is asked **once per application**: later connections won't show it again, and that's normal. On the first connection the MCP key opens **the home memory only** (the installation's default memory if the person has a membership there, else the first one granted — you spot it by the little house in the table); the rest you grant from the **Memories** action. In practice: the **first** membership you assign to that person (chapter 11) becomes their home, and the MCP key opens it on its own — the tick in **Memories** is only for memories *beyond* the home. An email never enabled before gets registered but stays **pending**: the agent receives a clear message. You enable it from chapter 11 (Admin) — but for the agent to have a memory to work in, assign it a **membership** (**Approve** alone just opens the console to the person, who then creates their first memory there). Once it has a memory, the agent finds it at its next startup: just open a new conversation or ask it to re-run `ckb_boot`. **The thing to remember.** When you create or rotate an API key, the **secret is shown only once**, right after. Copy it immediately and hand it to the agent: it can't be retrieved later, only regenerated (rotated). It's a house key: whoever holds it can act on those memories. MCP keys don't have this problem: no secret, just the login. **In practice.** For a colleague or a tester: send them to the **"Connect your agent via MCP"** section (or hand them the connector URL) → they connect on their own and show up "pending" in Admin → there you assign them a **membership** on a memory (so their agent has one, at the next startup). For a script or a *headless* agent: first **create the memory** (Memories tab, next chapter), then **mint the API key** here → copy the secret on the spot → hand it to the agent along with its **manual** (Guide tab). From there the agent knows how to read and write in the memory. --- ## 9. Memories — the registry of spaces **What it's for.** It's the **registry** of all memories: it lists them, gives **birth** to new ones and — for super admins — pauses or deletes them. (Remember: a *memory* is an independent knowledge space, with its own documents, history, and boot set.) ![The memory registry](/guide/en/memorie.png) **What you see.** A table with one row per memory: - **Memory** — the name. The crown marks the system memory. - **Current** — a green check on the memory you're working in right now. - **Status** — a music-player symbol: **green play** = active, **red pause** = paused (a paused memory exists but isn't accessible until you reactivate it). - **Members** — how many people have access. - **Created by** and **Created** — who created it and when. - **Actions** — the buttons to **pause/reactivate**, **delete**, and **switch** to that memory (the arrow). They appear on every row for consistency, but are **enabled only when it makes sense**: for example you can't act on the **current** memory, the **system** one (the factory memory with the crown), or the **default** one (the base memory worked in by default — in the demo it's `centro`, which here is also the current one); and pause/deletion are reserved to super admins anyway. When a button is off, it's greyed out. - Among the actions there is also the **feedback bubble**: it governs that memory's **product-feedback transmission** (on by default). When on, the agent can report bugs and ideas **about the service** to whoever develops ARCA — never memory content, and the report is sanitized by discipline: no names, data or secrets. The switch belongs to the memory's **owners** (and super admins); off = the memory sends no reports. - Finally there is the **OKF export** button (the download icon): it downloads the memory as an **Open Knowledge Format bundle** — a zip folder of markdown files readable anywhere, the open interchange standard. It is your *anti lock-in*: your data leaves in the standard whenever you want. Mind the boundary though: **it is not a backup** — it is a readable snapshot of the live objects; the complete, replayable history lives in the service's event log. This button too belongs to the **owners** (and super admins), and works even on a paused memory. At the bottom, the **Create memory** button (if you have permission). **What you see — creating a memory.** The button opens a wizard: ![The creation wizard, with seed and modules](/guide/en/memorie-wizard.png) - Type the **name** (the *slug*: a short, lowercase name, no spaces, also used in addresses). A live check tells you whether it's valid and available (wait for the green "Name available"). You can add a more readable **display name**. - Choose where it starts from: **Empty** (only the *initial map* — the index every memory generates automatically: which is why no memory is ever truly empty) or from a ready-made **seed** (a knowledge template). - If the seed has **modules**, a checklist appears: tick the ones you want poured into the new memory (none by default; there's "Select all"). Each module says how many folders and files it brings. - **Create memory** (enabled only after the green "Name available"). At the end, a recap reminds you of something important: you are the **owner** of the new memory — but for an **agent** to work in it you still need to grant it access from the **Tokens** tab. With the **OAuth connector** (Claude/ChatGPT): grant the memory to its key from the **Memories** action (and the person's *very first* memory becomes the home, which the agent opens on its own at the next startup — chapter 8). For a **headless**/script agent: mint an **API key** instead. **In practice.** Create the memory → then grant the agent access from the **Tokens** tab (connector: **Memories** action; headless: **API key**). Being owner isn't enough on its own: the agent's access is governed from Tokens. --- ## 10. Guide — the help inside the console **What it's for.** It's the help center inside the product: the guide you're reading. It opens right here, on the **Console tour** — the screen-by-screen walkthrough — with a **table of contents** beside it to jump to any section. From here you also reach the two sibling sections: **"Connect your agent via MCP"** and **"Type glossary"**. ![The Guide tab](/guide/en/guida.png) **What you see.** On the left the **contents** of the Tour (this guide): its sections, grouped — the intro, the numbered screens, the closing — with the one you're reading highlighted. Click one to jump to it. Below the contents, the two sibling sections: - **Connect your agent via MCP** — the fast way to connect Claude, ChatGPT or others: what MCP is and the steps for each client, with the connector URL in plain sight. At the foot you'll also find the **technical manual** (in English, for the machine) the agent reads on its own, to **copy** and hand to a *headless* agent. - **Type glossary** — the 7 document types, each with its icon and a plain-words explanation, so you recognize at a glance the symbols you see in the document tree. On a small screen the contents become a **bar at the top** that follows the current section: tap it to open the list and jump anywhere. **In practice.** To connect an agent, start from **"Connect your agent via MCP"**: the normal way is the **OAuth connector** (Claude/ChatGPT, no key). For a *headless* agent: mint an **API key** in the **Tokens** tab, then **copy the technical manual** from there to hand over. --- ## 11. Admin — people and access > This tab is seen by **administrators only** (it's last because it groups > administration). If you don't see it in the sidebar, that's normal: it's > not a defect, it's your role. **What it's for.** Managing **who can enter** the console and **what they can touch** — two distinct things: **approval** ("may enter, full stop") and **membership** (access to a single memory, "what they see"). New logins arrive here "pending approval": this is where you enable them. **First, the roles.** In ARCA permissions live on different planes — keep them separate: - **A person's system role** (applies to the whole console): the one under your name in the sidebar. **User** (enters and works in the memories they've been added to, no administration), **Admin** (also sees this tab and manages access), **Super admin** (can do everything: change roles, pause or delete memories). There's also **Disabled** (access suspended: that person no longer enters — you'll never see it as your own active role). - **A person's membership** (inside *a single* memory): **Owner** (owner of that memory) or **Member**. - **A key's level** (for **AI agents**, inside a single memory): **Member** or **Admin** — you set it when you mint the key (chapter 8). It's the *agent's* power, not the person's. Same word, different contexts: "**Admin**" is both a system role (a *person* who administers the console) and a key level (an *agent* that administers *that* memory); "**Member**" is both a membership and a key level. Always look at *whose* (person or agent) and *where* (the console or a single memory) you're talking about. ![The Admin tab with users, roles, and access](/guide/en/admin.png) **What you see.** A table with one row per person: - **User** — avatar, name, and email. - **Role** — the **system role**. Super admins can change it from the dropdown (never on themselves). - **Memories / access** — the memories the person has access to, as tags with their membership on each (Owner or Member) and an **x** to remove access. Someone with none shows one of two states: "**pending approval**" (not enabled yet — their login bounces) or "**approved — no memories**" (enabled but with no memory: they enter and see the welcome screen). Two actions here: **Approve** (only for those still pending) enables the login, full stop; **Add membership** grants access to a memory — and approves automatically, if it was needed. - **Last login** — when they last entered. **In practice.** A new person arrives — usually by connecting Claude or ChatGPT via OAuth (chapter 8) → you find them "pending approval". Two paths, with different effects on the already-connected **agent**: **Add membership** on a memory → the agent gets that memory to work in, at its next startup (the path to prefer for a tester with an agent); or just **Approve** → you enable console access, where the person finds a **welcome screen** and creates their own **first memory** (becoming its owner) — and only then, at the next startup, does the agent see it. In short: *Approve* opens the door for the person, *Add membership* hands the agent a memory. Removing a membership is possible, but the console first shows you **what it drags along** (for example which keys lose access): read the recap before confirming. --- ## 12. Team — people and permissions per memory **What it is for.** Working on the same memory with several people (and several agents), each with tailored permissions. The tab has two faces: - **Owner** — the memories you own. From here you **invite** a person (they must have signed into ARCA at least once: the invite shows up in their Team tab and counts only once accepted), change member **roles** (owner / member), and define **ACL groups**: a **permission level** — *Read only*, *Read & write*, *Write & delete*, *Full access* — plus a **blacklist** of folders and files that simply **do not exist** for that group (they vanish from the tree, the maps, the agent's boot and the search). Mark a folder with the ✕ and everything inside is covered. A member **without a group** keeps full member access: groups only restrict, never widen. - **Member** — the memories you belong to: **pending invites** to accept or decline, your group **with its level** (the reserved perimeter is not shown to you: hidden paths simply do not exist for you), and the button to **leave** a memory. **The point that matters:** permissions also bind the **API keys** and the connected agents — a key always inherits its owner's permissions, re-evaluated on every call. Change the group and it applies immediately, to the console and the agents alike. Removals and leavings revoke the grants of the affected keys in cascade (as in the Admin tab). --- ## The thread that ties it together If you only remember five things: 1. **Always check which memory you're in** (selector, top-left): everything applies to that one. 2. **You correct the text and leave post-its; the agent does the structure.** That's the helm model. 3. **Every change is tracked** (who/what/why) and **nothing is lost**: the history (the clock) can always be rewound. 4. **The star ★** marks what the agent loads first (the always-on set); you curate their **order** and **weight** in the **Boot** tab. 5. **Letting an agent in**: start from **"Connect your agent via MCP"** — the simplest way is the **OAuth connector** (Claude/ChatGPT connect on their own, no key); alternatively a **key** from the Tokens tab, whose **secret is shown only once**. The rest you learn by using the console: open a document, correct a line, send it with Push. The memory keeps count for you.