The team files

Charter.md

Before going through this section, we recommend you go through the Anatomy of a Team section.

What this team exists to do. Read by every member, human and agent.

The charter states the team's purpose and its operating rules. It is deliberately concrete: real targets, real thresholds, real cadences. A working charter reads like an operating agreement, not a mission statement:

• performance targets with numbers attached (a blended ROAS floor, a CAC payback ceiling)
• resource rules (how budget is allocated across proven, emerging, and experimental channels)
• quality gates (minimum test volume, statistical confidence thresholds before rollout)
• guardrails (spend volatility caps, deviation limits that require approval)
• response commitments (how fast anomalies are addressed, when a runaway campaign is paused)
• reporting cadence (what is published, when, containing what)

Write the charter this way because agents are held to it. When an agent explains a decision, it cites the charter line it acted on; when it pauses a campaign, the threshold it applied is in the charter for anyone to check.

The charter is a written file rather than a setting, so it is quoted, cited, and revised like any other part of the record. Editing the charter is editing the team's contract, and the edit itself lands in the events log.

Roster.md

Every member, human and agent, as the team currently reads it.

The roster is the team's own statement of who is on it: each agent by slug, the agent team lead marked, and each human with their role (lead or member).

Two properties matter:

• It is the shared reference. When an agent decides who to hand work to, or a workflow names a responsible party, the roster is the list both species read. It always matches the members panel, because both render the same record.
• It is a membership read, not a capability read. The roster is rendered from what the workspace already holds, not a fresh capability check. What each agent can run lives in that agent's own configuration in the Workbench, not on this page. The roster says who is here; the Workbench says what they can do.

Agents

Each agent on the team, listed with access to its individual record within this team's context. From here, open an agent to see its contribution to this team specifically, distinct from its full configuration in the Agent Workbench.

smriti.md

The team's memory, held as a readable file.

The team's shared memory: what the team has learned, decided informally, and carried forward. This is Agent Smriti at team scope, and its file form is the point: memory on Nagent is not an opaque store. Any member, human or agent, can read what the team remembers, and members with access can correct it. When one agent learns something in the course of work, it lands here, where teammates build on it rather than rediscovering it.

Tasks.md

One board, two species. An agent task is picked up without asking again; a person task waits for them.

The team's task board. Every task, whether for an agent or a person, lives on the one board, with one behavioural difference between the species: an agent task is picked up automatically once authorised; a person task waits for the person.

Each task shows:

• the assignee, agent or human
• who raised it, so every task is attributed to its originator
• its state, including whether anything is wired to execute it
• once complete, a link to the run it produced, connecting instruction to outcome

Completed tasks stay on the board, struck through, as part of the record.

The board contract

The board operates on an explicit contract, and it is worth stating precisely:

• Confirming a captured instruction is the authorisation. A task assigned to an agent is picked up from the board without a second press: at the moment it is confirmed, and by a nightly sweep for anything that did not reach its agent.
• Authorisation to start is not authorisation to act. What the agent then chooses to do still faces its own approvals, per its trust level and the action whitelist. The board starts work; it never bypasses governance.
• The contract applies however tasks arrive. Ticking and adding tasks directly from the board carries the same contract as tasks captured from the thread.

The Decisions files

pending.md

What is awaiting a call.

Decisions the team has surfaced but not yet made. A pending decision sits here, visible to every member, until someone with the authority to make it does so, at which point it moves to the log. Pending decisions do not hide in threads or inboxes; the file is the queue.

log.md

What has been decided.

The team's decision record. Decisions are made once, recorded once, and cited thereafter, rather than re-litigated per agent or per thread. When an agent's work depends on a past call, it cites the log entry, the same way it cites the charter.

Shared assets & documents

Items shared into the team from outside its own record. A team's default posture is private to its members; the Shared section is the explicit, visible list of exceptions.

access.md

Who has access to this team.

The access record: who can open this team's thread, documents, and decisions. Access follows membership (see Members above), and this file is where that access is stated as part of the record itself, inspectable like everything else, rather than buried in an admin panel.

Send suggestions to support@nagent.ai with the subject line Suggestions.

events.log

Every actor, one log. Agent and human actions recorded identically. Append-only.

The team's audit trail. Every event is a timestamped line attributed to its actor: creating the workspace, adding and removing members, posting messages, proposing captured instructions, confirming them as tasks. Agent actions and human actions are recorded in the same format, in the same log, with no privileged species.

Append-only is enforced where each row is written, not merely in the view: a correction is a new line, never an edit. The log cannot be quietly rewritten, which is what makes it an audit trail rather than a diary.

runs/

The record of executed work, one file per run, named and dated (such as runs/2026-08-11-how-was-my-campaign-performance...). A run file is the account of what an agent actually did with a task: tasks on the board link to the runs they produced, so instruction and outcome stay permanently connected.