Concepts
A dozen words cover most of pcx. Learn them once and every screen of the app and every tool of the API reads the same way.
Organization
Section titled “Organization”The account your team shares: its members and their roles, its API keys, its plan and the modules it runs. You can belong to several organizations and switch between them at the top left of the app. A daemon you connect shows there as a space of its own.
Workspace
Section titled “Workspace”One project, usually one repository. A workspace has its sessions, its project card, its board and its entity graph. Searches with scope: "workspace" look across all of its sessions. A workspace can be archived: it keeps everything and leaves the lists.
Session
Section titled “Session”One line of work inside a workspace: a feature, an area of the code, a board, an agent’s conversation. A session holds its records and its conversation, the turns of the chat that produced them. The Claude Code plugin gives each project one session; you can make more.
Record
Section titled “Record”One piece of knowledge, written by your agent (or by you). Every record has a type, a title, a description, the entities it mentions, its author and when it was written.
| Type | When it is written | Example |
|---|---|---|
decision_made |
a choice with its reason | Use Stripe Payment Intents for card payments |
problem_solved |
a bug and its fix | Customers charged twice on a double click |
code_change |
a change worth knowing about | Tax is computed by TaxJar at confirm |
requirement_added |
something the system must do | Guest checkout without an account |
concept_defined |
a term of the project | Cart version |
qa |
a question that was answered | Why do refunds take a day to show? |
Writing a record costs no model call: it is stored and embedded at once.
Entity and relation
Section titled “Entity and relation”The things records talk about: a technology (Stripe), a code component (checkout-api), a concept, a problem, a solution, a decision. Each has a type, aliases and the records that mention it. A record can also relate two entities with one of eight relations: depends_on, implements, caused_by, leads_to, related_to, required_by, conflicts_with, solves.
The entities and relations of a workspace form its graph. Search uses it to bring back what a hit touches, and views like impact (“who depends on this?”) and lineage (problem, decision, consequences) read it directly.
Current and ended
Section titled “Current and ended”Facts change, history stays. A record ends when a later one supersedes it, when a later one says the opposite, or when you forget it. An ended record is never deleted: it fades in the app, keeps the reason it ended, and ranks lower in search.
In the example above, “Keep the cart in Redis with a 7-day TTL” ended when “with a 30-day TTL” replaced it. The app shows the first as Superseded and the second as Current.
Two short notes put in front of every session of your agent:
- the project card of a workspace: its stack, conventions and current goals;
- the user card: your own preferences, the same in every project.
Every change is a new version; two writers never overwrite each other. Edit them in the app under Cards, or let your agent update them. Why they live in memory and not in a file of the repo: Cards and context for a task.
Module
Section titled “Module”What the pcx host runs. post-cortex, the memory, is one; the board, the team, workflows, the scheduler, HTTP, mail and others are modules too. Each declares its tools and what it needs (to write memory, to reach the network, to read files). It gets only what the organization grants it, and every call is checked. See Modules.
Board, decision and approval
Section titled “Board, decision and approval”A board holds tasks in columns, each with its thread of comments. A decision on a task records what was decided, why and by whom, and its risk: code, money, data, operations or none. A decision with a risk holds its task until a person approves it; every one of them waits in Approvals. Decisions and approvals are written to memory, so the next agent knows why. Why a board: The board.
Team and trust
Section titled “Team and trust”A team is a set of members, agents or people, each with a role and what it may do on the board. An agent member works by itself when a task is assigned to it or a comment mentions it. The team’s trust, set by a person, says which decisions with a risk it may approve by itself, within limits; by default every one waits for a person. See Teams.
An agent pcx runs for you: the organization’s own agent, the chief, a team’s members, the workflow builder. Each calls a model of your model provider and only the tools of the modules it may use. You talk to them in Agent.
Workflow and job
Section titled “Workflow and job”A workflow is a graph of steps that runs when something happens: by hand, at set times, from a webhook, on an event. Each step calls a tool, asks a model or an agent, waits, or waits for a person. It calls only the modules its grants name, and a person approves them before it runs. A job of the Scheduler starts a workflow, or adds a task, at set times. See Workflows and Scheduler.
Author
Section titled “Author”Every record, message and card keeps who wrote it: claude-code, cursor, a team member like hermes:reviewer, or a person. Search can filter by author or prefer your own agent’s records.