Manage an organization and projects

An Anectico organization is the team and billing boundary. Projects separate application data inside that organization. Choose a project before you ask your agent to investigate or configure anything. Your agent names the project in each call (the CLI takes --project). In the Console, the project switcher in the header picks the working project for the control pages, and a proof page always uses the project named in its own link.

You control three things here: who is in the organization, which projects exist, and what the audit trail shows. In the Console, open People (/people), Projects (/projects) and Audit log (/audit-log). See the Console guide. Your agent can read and change the same things.

Ask your agent

"List my projects and tell me which one this key is bound to."

"Show the audit events from the last day where a request was denied."

Job	MCP tool or action	CLI command
List projects or read one	list_projects, get_project	anectico projects list, anectico projects get <project-id>
Show the project in effect, or choose a default	none	anectico projects current, anectico projects use <project-id-or-slug>
Create or rename a project	create_project, update_project	anectico projects create <name>, anectico projects update <project-id>
Delete a project	delete_project	anectico projects delete <project-id>
List members and invitations	list_members, list_invitations	anectico members list, anectico invitations list
Invite, revoke an invitation, change a role, remove a member	create_invitation, revoke_invitation, update_member_role, remove_member	anectico invitations create, anectico invitations revoke, anectico members set-role, anectico members remove
Read the audit trail	list_audit_events	anectico audit list

Reading projects needs projects:read, and creating or editing needs projects:write. Reading members and invitations needs members:read, and changing them needs members:write. The audit trail needs audit:read. Every administration write through MCP or CLI first prints the server's complete before, proposed, required scopes and consequences. After approval, repeat identical arguments with confirm_token or --confirm-token; see MCP tools. Reading the prior project or membership also requires its read scope. Deletion additionally needs projects:delete. Project and invitation creation take a stable idempotency_key; CLI generates and prints it when omitted on preparation. Reuse it unchanged when confirming or retrying.

Project, member and invitation inventories are pages. Use --limit and --cursor in the CLI, or limit and cursor in the read action; follow next_cursor until has_more is false before claiming a complete inventory. Defaults are 50 and the maximum page size is 1000. Project lists also accept is_active / --is-active, and member lists accept a role filter. Counts describe the returned page. Project descriptions can be cleared with an explicit empty value; sampling and active state can be changed. Retention is always derived from the organization's policy.

Create and choose projects

In the Console, open Projects (/projects) to create a project with a stable name and slug. Use separate projects when data needs a real access or lifecycle boundary. Use the environment field within one project for production, staging, and development when the same application should remain searchable as one system.

If project creation reports that setup is temporarily unavailable, wait and retry. After a timeout or lost response, retry identical creation arguments with the same key to recover the first project. The retry cannot create a duplicate or resurrect a deleted project. A new creation with an existing slug returns a conflict.

Project controls follow the signed-in principal's exact permissions. projects:read returns the project list and any single project's record, and is available to every role, which is what keeps the project switcher and the Projects page populated; projects:write additionally exposes create and edit actions, while projects:delete separately exposes deletion. Without either write capability, the Projects page keeps the project list visible in a clearly read-only state. An API key with no projects:read cannot list projects at all — give an ingestion-only key its project at mint time instead. A newly provisioned organization with projects:write can still create its first project from the Console when its project list is empty.

The project switcher stays in the Console header on desktop, tablet, and mobile. It and the Projects page load every project, including organizations with more than 50 projects. Reloading preserves your selected project while that list loads. A failed load does not switch you to another project. When the complete list confirms your selected project is gone, the Console selects the default project, or the first available project if there is no default.

After creating a project:

1. select it in the project switcher;
2. create or scope an application key with the required telemetry permissions;
3. configure every participating SDK or collector with that key; and
4. send a test signal before rolling out broadly.

An organization must keep at least one project. Deleting a project is destructive; verify which SDKs, alerts, API keys, dashboards, and automations refer to it first.

Cleanup runs in the background after project or organization deletion. Once the tenant deletion boundary is applied, matching product events, logs, traces, metrics, agent events, error events, error groups, and evaluation results stay hidden from telemetry reads, including organization-wide searches and earlier queued deliveries that arrive late. Deleting one project preserves sibling projects. Read suppression and physical storage reclamation are separate; a successful project-delete response does not mean every background cleanup has already finished.

After they are hidden, the project's logs, traces, metrics, agent events, error events, error groups, evaluation results and the values of its log-based metrics are deleted from storage in the background, a few minutes later, along with its product events. A record that was still in transit when you deleted the project and arrives after that cleanup stays hidden and is removed when your data retention period for it ends.

Deleting a project also deletes its cohorts with their member lists, its feature flags, saved insights, tracking plans, experiments and surveys. A change to one of them that was already on its way when you deleted the project is refused and creates nothing.

Deleting a project also deletes its incidents, with their timelines, evidence, retrospectives and action items, and its response catalog of services and runbooks. No new incident can be opened in a deleted project, and it sends no further incident notifications. A Slack channel created for one of its incidents stays in your Slack workspace.

Deleting a project also deletes its uptime, certificate, domain and heartbeat monitors, their check history and its maintenance windows. Checks against your endpoints stop, and heartbeat URLs for those monitors stop accepting pings.

Deleting a project also deletes its escalation policies and on-call schedules, and stops any escalation still running for its alerts. Your people's contact methods are kept, because they belong to your organization; deleting the organization erases them too.

Deleting a project also deletes its notification history and any notification still waiting to be retried. Your notification channels and templates belong to the organization and are kept; deleting the organization erases them, including the webhook addresses and tokens they hold. It also erases the organization's stored connection credentials; see Connections and notifications for what stays authorized at each provider.

Deleting a project also erases its recorded agent session replays and outbound agent attempts. Its evaluators, sampling rules, datasets, experiments, release gates and annotations are erased too, and automatic evaluation of the project stops. Its agent registry — agents, versions, deployments, quarantines and action receipts — is erased as well. So are its links between issues and your tracker tickets; the tickets themselves stay in your tracker. Pending exports stop, and export files already produced are deleted. Its anomaly findings are erased. The searchable copy of those action receipts is removed with the project after writes already in flight have settled. Later deliveries cannot restore it. In a project you do not delete, an action receipt is kept for up to 400 days: older entries leave the ledger, oldest first, and what remains is still verifiable (see Verify attestations). Erasing a person removes what a receipt said about them sooner, from the ledger and from the searchable copy.

Deleting a project also deletes what the issue tracker holds for it: the status, assignee and resolution notes of its issues, the history of changes to them, merged-issue links, the source maps and symbol files uploaded for it together with the record of who uploaded them, and its release details. An issue first seen before this was introduced, and never scored, is removed when the organization is deleted. Its account segments and the review signals raised for its agents are deleted too. The identifiers of the people seen in the project are removed from storage in the background, a few minutes later. Alert silences and the repository connection used for suspect commits belong to your organization and are kept; deleting the organization erases them.

Project-scoped credentials are pinned to their signed project for project reads, updates, deletion, and project configuration. Passing a different project_id cannot widen access. Exact project lookups also return the same not-found response for a missing project and a project outside the credential's organization, so callers cannot use the endpoint to discover another tenant's IDs.

Invite and administer members

In the Console, open People (/people) to review everyone who can access the current organization and confirm each person's role. Check the organization and your own role before you change configuration. Owners and admins can invite a teammate from this page by entering the person's email and choosing Admin, Member, Developer, or Viewer. Anectico emails a single-use acceptance link to that exact address and shows the invitation as pending until it is accepted or revoked.

The invitee signs in with the invited email before accepting. Acceptance switches that browser to the shared organization and clears cached data from the invitee's previous personal workspace; the personal workspace itself is not deleted or merged. The same invitation operations are available through the Anectico CLI:

anectico invitations create engineer@example.com --role ROLE_MEMBER
anectico invitations list
anectico members list
anectico members set-role <user-id> ROLE_ADMIN
anectico members remove <user-id>

The People page loads the complete roster. For a large workspace, anectico members list --limit 50 returns one page and its pagination state; pass the returned next_cursor unchanged with --cursor to continue. The member list defaults to 50 per page and accepts up to 1000.

An emailed invitation link resumes after you sign in. Anectico keeps the return path in an HttpOnly, same-origin cookie for the login round trip and removes the invitation token from the address bar once the acceptance page loads.

Only grant an admin role to people who need organization configuration or destructive capabilities. Removing a member does not rotate credentials they created; review and revoke unnecessary API keys separately.

A removal takes effect immediately and permanently: the moment the request succeeds, that person has lost access to the organization. The member list is rebuilt a moment behind it, so a list reloaded right after a removal may still show the person for a second or two. Reload again rather than removing them a second time — the first removal is already final, and a repeat only reports that there is no longer such a member.

anectico members remove tells you which case you are in. With --output json it prints the server's MCP result, including its structured receipt and projection warning. A warning that the roster is catching up means removal is final but roster verification is pending; re-read with anectico members list. Table output prints the server's text directly.

Current organization roles are Owner, Admin, Member, Developer, and Viewer. Owners and admins receive organization configuration and destructive permissions. Members and developers receive the collaborative and operator surface, including self-service API-key management. Viewer is a read-only security boundary: viewers can inspect telemetry, dashboards, settings, and usage but cannot ingest, acknowledge, respond, edit, create, revoke, or delete product state. Viewer is also the one role that sees less telemetry, not just fewer actions: it can list session recordings, agent runs and customers, and cannot play a recording back, open an agent run's transcript, or read a customer's profile properties. Choose Member for anyone who needs recorded customer content; see Permissions and scopes. The People page requires confirmation before changing another member's role, and role changes take effect in a newly issued or refreshed session token. Existing API keys keep their stored scopes and must be reviewed or revoked separately after a demotion.

Verify context before acting

Open the account menu in the Console header to confirm the signed-in name, email, workspace, and role. In the CLI, use anectico projects list and anectico projects use <slug> before a write. For automation, prefer a project-scoped key rather than relying on the operator to remember a project flag.

Owners and admins can open Audit log (/audit-log) in the Console to inspect the organization audit trail. Your agent reads the same record with list_audit_events or anectico audit list. The record shows actor, action, resource, result, time, and allowlisted target context — including, for an action taken by an agent, the tool it used and that it arrived over the agent interface. It deliberately omits network identifiers, user agents, and arbitrary metadata.

The result field, and its filter, distinguishes a change that was applied from one that was refused, previewed, throttled or errored. Filter on denied to see what a credential tried and was not allowed to do; see Review what the agent did for the full vocabulary. Members, developers, and viewers do not receive audit:read by default. For API-key lifecycle events, the verified user or API-key actor is shown separately from the key being created, renamed, scope-edited, or revoked. If an older event did not record an actor, the view says the actor is unknown rather than guessing from the target.

• Authentication and API keys
• Permissions and safe actions

A creation retry previews the current project or invitation unchanged, alongside the original recorded result. An edited or deleted project and an accepted or revoked invitation are never recreated or resent by a retry. Preserve the same request key and arguments.

API-key scope edits must stay within the credential's purpose. Intake keys keep only their intake permission; application keys keep only application delivery. Both may be cleared. A contained key requires its quarantine to be lifted before a scope edit. Previews show last-use observations, but subsequent credential use alone does not invalidate approval of the displayed configuration.