Documentation

Guides, setup steps, and runtime reference

GitHub-style docs, tuned for operators

Everything you need to set up, load, share, and operate myagents.

This page is the full product guide: install the CLI, sign in, create agents, connect services, load profiles locally, share team agents, publish public pages, and debug the common failure modes without guessing.

Quick start

Human terminal

curl -fsSL https://myagents.sh/install.sh | bash
myagents login
myagents load <slug>

AI agent bootstrap

Go to myagents.sh/setup and install myagents for me.

Jump to

How myagents works Install the CLI Sign in and transfer the session Use the dashboard Create your first agent Load an agent into your local runtime Connectors vs environment variables Knowledge, files, and durable context Policies, API keys, and webhooks Teams and shared agents Public pages, manifests, and runtime surfaces Core commands Troubleshooting

Overview

How myagents works

myagents gives each AI agent one portable profile: identity, instructions, credentials, knowledge, policies, connectors, and activity. The dashboard edits that profile, the CLI loads it into local runtime state, and the public routes expose a safe published surface when you want an agent discoverable.

Create or sign in to your account

Use the official Clerk-hosted sign-in or sign-up flow. The browser methods shown there come directly from your Clerk configuration, the hosted card is themed through the shared myagents appearance layer, and the resulting user is mirrored into Supabase so dashboard state, CLI sessions, and Vault-backed secrets stay in sync.

Create an agent profile

An agent stores the permanent context you want available every time it runs: instructions, identity details, environment variables, linked services, files, memory, policies, and API keys.

Load the agent where work happens

Run `myagents load <slug>` and the CLI refreshes the active session, syncs the myagents skill, syncs the per-agent skill, and restores the current local cache for that agent.

myagents load <slug>

Key points

Dashboard edits the agent profile.
CLI loads and refreshes the agent profile locally.
Published routes expose only safe public metadata.

Setup

Install the CLI

Install once per machine. After that, the same binary handles login, load, diagnostics, credentials, resources, teams, and publishing flows.

Install from the website

The install script pulls the correct platform binary from the website and wires up the `myagents` command for the current machine.

curl -fsSL https://myagents.sh/install.sh | bash

Give another coding agent the bootstrap prompt

If another AI agent is setting up the machine for you, send it to the terminal-first `/setup` route instead of asking it to click around the website.

Go to https://myagents.sh/setup and install myagents for me.

Verify the install

Run the health and version checks before you start creating agents so you know the machine is wired correctly.

myagents doctor --json

Key points

Use `/setup` for agentic bootstrap and `/install.sh` for direct human terminal install.
The CLI downloads from `/bin/*`, which is backed by Blob-hosted release binaries.

Auth

Sign in and transfer the session

The clean default flow is browser handoff. The CLI opens the browser, the user signs in or signs up, and myagents returns a short-lived handoff code that the terminal exchanges for the local app session.

Use browser handoff for login

This is the best path when the browser might already have an active Clerk session. If it does, the browser can skip the login form and send the session back to the terminal immediately.

myagents login

Use browser handoff for signup

New users can sign up in the browser and the CLI still receives the resulting session automatically through the same localhost callback flow.

myagents signup

Key points

The browser uses Clerk’s hosted Sign In and Sign Up components.
The exact browser methods come from your Clerk instance settings, including Password when it is enabled.
Let the hosted Sign In screen own the social sign-in-or-sign-up continuation instead of forcing a separate sign-up URL inside the sign-in widget.
The CLI stores local auth after the handoff so later commands can refresh and reuse it.

Dashboard

Use the dashboard

The dashboard is the source of truth for agent editing. It is where you create the agent, shape its instructions, manage credentials, attach knowledge, review activity, and configure sharing.

Open your workspace

After sign-in, the dashboard redirects to your personal agent workspace. Team workspaces appear alongside personal agents when you belong to a shared team.

Use the main agent page instead of hunting through old sub-pages

Identity, environment variables, linked accounts, knowledge, policies, webhook controls, and API keys now converge into the unified agent detail page and settings dialog.

Use recent activity and settings as companion screens

The dashboard prefetches likely next pages such as Recent Activity, Settings, New Agent, and New Team so first navigation feels instant rather than blocked.

Key points

Personal dashboard stays focused on agents.
Recent Activity lives at `/dashboard/activity`.
Settings holds appearance and workspace-level preferences.

Agents

Create your first agent

New agents start with one slug-safe identity field. That same dashed identity becomes the agent name, the slug, the public URL fragment, and the default `myagents load <slug>` command.

Choose one dashed identity

Use lowercase letters, numbers, and dashes. Spaces are normalized into dashes automatically so the saved agent identity is stable everywhere.

Add the instruction set

Write what the agent is for, how it should behave, and how it should use tools. This becomes part of the generated local skill and the public markdown surface if the agent is later published.

Set the essentials before loading

The fastest productive first setup is: create the agent, add environment variables or connectors, add instructions, then load it locally.

Key points

Agent identity is intentionally fixed after creation.
If you need a different identity later, duplicate the agent and use a new dashed identity there.

Runtime

Load an agent into your local runtime

Loading is the main daily command. It refreshes auth/session state, restores the active agent profile locally, syncs the global and per-agent skills, and prepares the credential model you selected.

Check your current state

Use status first if you are not sure whether you are signed in or whether another agent is already active.

myagents status --json

Load the chosen agent

This refreshes the local session and skill state for the target agent. It is the main “start work” command for both humans and AI agents.

myagents load <slug> --json

Avoid the write-then-load loop

After your own successful CLI write on the same machine, myagents already refreshes the local cache silently. Reload only when you switch agents or need remote changes from another machine or from the dashboard.

Key points

Use `--credential-mode on-demand` when you do not want a local `.env` file.
Use `--download-linked-skills ask|yes|no` when the agent has GitHub-linked skills.
Disabled agents will reject future loads until re-enabled in Agent settings.

Credentials

Connectors vs environment variables

This is the most important dashboard distinction. Use connectors for guided sign-in or MCP-style connection flows. Use environment variables for raw API keys, service tokens, and one-off secret values.

Use Connectors for login-style flows

GitHub OAuth and remote MCP connectors belong here. Connector metadata is synced into Claude Code so login-style integrations can be used as proper runtime connections instead of raw env vars.

Use Environment Variables for manual secrets

Raw secrets such as `OPENAI_API_KEY`, `STRIPE_SECRET_KEY`, `SLACK_BOT_TOKEN`, or `SUPABASE_ACCESS_TOKEN` should be added as environment variables with preset buttons when possible.

Choose the credential delivery mode

Leave the default mode on for a local env cache, or turn on On-demand mode in Agent settings when you want `myagents credentials <provider>` to fetch secrets just in time.

Key points

Connectors are for OAuth and remote MCP handshakes.
Environment Variables are for raw secrets and tokens.
Secrets remain stored server-side and are not exposed on public routes.

Context

Knowledge, files, and durable context

The main agent page separates long-lived context into clearer buckets so you can inspect exactly what the agent knows and why.

Upload files

Store PDFs, screenshots, docs, CSVs, and other source material that the agent should be able to revisit later.

Add reference notes and memory notes

Reference notes hold durable docs and guidance; memory notes hold evolving context the agent should keep over time.

Attach skills deliberately

Skill files and linked GitHub skills belong here too. Linked GitHub skills should stay metadata-only in myagents itself, then `myagents load` can offer the local download/install step later.

Key points

Knowledge & Files is the main long-lived context area.
Each item can be expanded to inspect metadata or contents.
Per-agent caps apply to manual env vars and skill resources.

Controls

Policies, API keys, and webhooks

Agent settings and the policy area control how the agent is allowed to operate and how external systems can talk to it.

Use policies for guardrails

Create HITL, rate-limit, and allowed-domain rules so the loaded agent skill and runtime behavior keep the same safety constraints.

Create API keys from Agent settings

The raw API key is shown exactly once at creation time. After that, the dashboard only keeps the inventory metadata and disable controls.

Enable the inbound webhook when you need machine-to-machine writes

Webhooks are managed from Agent settings too, with status controls and secret regeneration for HMAC verification.

Key points

Agent status, On-demand mode, webhook, API keys, and the encryption preview live in Agent settings.
End-to-end encryption is still a coming-soon per-agent passphrase flow, not an active feature yet.

Teams

Teams and shared agents

Shared agents let a team use the same agent profile while preserving access rules about who can edit shared configuration versus who can only inspect and use it.

Create a team workspace

Team pages let you create a new team, invite members, and manage roles for shared agent ownership.

Understand viewer vs admin

View-only collaborators can inspect shared connectors, environment-variable inventory, and API key inventory and use shared credentials. Admins can add, update, revoke, or remove that shared setup.

Check access role from the CLI before writes

The CLI status response stores `access_role` and `can_manage_shared_config` so you can verify whether the active shared session is writable before attempting a team change.

myagents status --json

Key points

Personal agents and team agents share the same mental model.
Team Settings should remain a visible header action in team views.

Publishing

Public pages, manifests, and runtime surfaces

myagents can expose a safe public view of an agent when you want to share capability metadata or a runtime-readable markdown profile without exposing secrets.

Publish the agent deliberately

Visibility is controlled from the dashboard. Private agents remain private across the human page, JSON manifest, and markdown route.

Use the public surfaces for machines and humans

The public page is the human-facing profile, the JSON manifest is machine-readable capability metadata, and the markdown route is a runtime-oriented instruction surface.

Keep identity and secrets separated

Public routes should never expose Vault references, raw credentials, or private identity fields. Those stay in authenticated dashboard and CLI session paths only.

Key points

Human page: https://myagents.sh/<username>/<slug>
Machine manifest: https://myagents.sh/<username>/<slug>.json
Runtime markdown: https://myagents.sh/<username>/<slug>.md

Reference

Core commands

These are the commands most people need every day. Start with install and auth, then load, inspect status, fetch credentials when needed, and run diagnostics when something feels off.

Account and state

myagents signup
myagents login
myagents status --json

Agent runtime

List agents, load one, and use on-demand credential fetches when you do not want a local env cache.

myagents agent list --json
myagents load <slug>
myagents credentials github --json

Health and maintenance

Run diagnostics whenever auth, session freshness, API reachability, or skill sync seems wrong.

myagents doctor --json

Key points

Use `--json` whenever another tool or agent will parse the output.
Use `credentials <provider>` only when the secret is actually needed.

Support

Troubleshooting

Most myagents issues reduce to auth state, agent state, or choosing the wrong storage surface for a credential or integration.

Auth is failing

Try `myagents status --json` first. If you are not signed in, use browser handoff again. If the browser opens but never returns, confirm the local callback port is reachable and the browser did not block the redirect.

The wrong thing is stored in Connectors or Environment Variables

Move login-style OAuth or MCP flows into Connectors. Move raw API keys and manual service tokens into Environment Variables. This distinction matters for local sync behavior and how Claude Code consumes the integration.

The loaded agent looks stale

Reload only when you need remote changes from the dashboard or another machine. If you just performed a CLI write on the same machine, the active local cache should already be refreshed.

Key points

Run `myagents doctor --json` before assuming a deeper bug.
Check Agent settings when loads or credential access suddenly start failing.
If the docs and the auth surface disagree, trust the Clerk and route configuration, then sync the docs.