# The Core — complete agent operating guide > The Core is a shared source of truth for a human and their authorised agents. Core Edge is the hosted service, CLI, API, and MCP access layer. Use this guide when you have no prior Core Edge skill or local repository context. Live MCP tool schemas and CLI help remain the command-level source of truth. ## Safety and access boundary - Durable access always requires human approval. - Never request passwords or credentials in ordinary chat. - Never place a Core key in source control, shell history, command arguments, or a global shell profile. - Agents use distinct named, scoped, revocable machine identities. - No anonymous durable workspace, agent-owned personal account, or agent-initiated email registration is currently available. - Authentication details and recovery guidance: https://core-edge.up.railway.app/auth.md ## Choose one connection path ### Hosted MCP Use https://core-edge.up.railway.app/mcp with OAuth/Dynamic Client Registration when the client supports it. Otherwise use the client's bearer-token field with a human-provisioned Core key. Follow https://core-edge.up.railway.app/mcp/setup. The public hosted MCP endpoint is the supported MCP path. Do not invent an npm or local stdio package. ### Core Edge CLI Install on macOS or Linux: ```sh curl -fsSL https://core-edge.up.railway.app/install.sh | bash ``` Install on Windows PowerShell: ```powershell irm https://core-edge.up.railway.app/install.ps1 | iex ``` Humans run `core-edge login https://core-edge.up.railway.app` and complete browser approval. Agents receive `CORE_AUTH_TOKEN` and `CORE_AGENT_NAME` through their harness or secret manager; they do not borrow the human session. Human signup begins at https://core-edge.slayteksystems.com/signup. ## Establish identity and one space Before reading or writing, verify who you are and which spaces you can access. - MCP: call `core_system` with `view: whoami`, then `view: namespaces`. - CLI: run `core-edge auth whoami --json`, then `core-edge space list --json`. Operate inside one explicit space. MCP calls include the `space` field where the schema requires it. CLI users select a stable default with `core-edge space use ` or override one request with `--space `. New records require an explicit destination space. Existing-record updates resolve scope from the record ID. Never guess a space from an unrelated visible list. ## First-session operating rules 1. Orient before dumping content. 2. Search before creating so you do not duplicate existing context. 3. Prefer typed records: notes hold durable context, tasks hold actionable work, and projects group related work. 4. Preserve relationships. A task can belong to a project; a note can provide project context. 5. Use `what-next` for the active queue and `space review` for stewardship. Do not teach deprecated compatibility commands as the normal workflow. 6. Keep destructive or administrative work human-reviewed. The default MCP surface intentionally omits key management, hard delete, approval review, migrations, and raw arbitrary API calls. ## Create the first useful shared context Start with a small real outcome rather than a tutorial-only placeholder. ### Hosted MCP path 1. Use `core_search` in the chosen space to look for the topic. 2. Use `core_capture` to create a note containing the decision or context. 3. Use `core_capture` to create an actionable task. Supply `project_id` when an appropriate project already exists. 4. Use `core_links` to discover allowed link shapes and `core_link` when an explicit relationship is useful. 5. Use `core_work` with `view: what_next` to confirm the task appears in the operating queue. 6. Use `core_discover` with `mode: stewardship_summary` to inspect the space without mutating it. The hosted MCP capture surface currently creates notes and tasks, not new projects. If no project exists, keep the first evaluation to a linked note and task or use the CLI path to create the project. ### CLI path ```sh core-edge search "example project" --space core-edge project create --space --title "Example Project" --status active core-edge note create --space --title "Example Project Brief" --content "The durable context for this project." core-edge task create --space --title "Run the first useful check" --project core-edge link has_context --dry-run core-edge link has_context core-edge what-next --space core-edge space review --space ``` Use real IDs returned by the service. Do not copy the placeholders literally. ## Prove continuity with a second fresh agent The defining evaluation is not successful storage. It is useful continuation. 1. Give a second fresh agent its own named credential for the same authorised space. 2. Verify its identity and space access independently. 3. Search for the project or topic without pasting the original briefing. 4. Read the note, task, links, and project context that the first agent created. 5. Ask `what-next`, explain the current state in its own words, and continue one bounded action. Pass only when the second fresh agent can recover the shared context without undocumented human explanation. ## Validate and recover - Authentication failure: restart from https://core-edge.up.railway.app/auth.md and the advertised OAuth metadata. - Missing or ambiguous space: list accessible spaces and ask the human which authorised space is intended. - Duplicate-looking result: search and read before creating anything else. - Write denied: do not widen scope; explain the current role and request human review. - Unexpected tool or command: trust live MCP schemas or `core-edge --help`, then report stale public guidance. - Product friction or contract drift: capture feedback through the supported feedback surface rather than inventing a workaround. ## Public references - Concise discovery: https://core-edge.up.railway.app/llms.txt - Authentication: https://core-edge.up.railway.app/auth.md - MCP setup: https://core-edge.up.railway.app/mcp/setup - Human-readable agent page: https://core-edge.slayteksystems.com/agents - Human signup: https://core-edge.slayteksystems.com/signup