Bring your Claude skills and memories
For a team already working in Claude Desktop or Claude Code with skills, memories, CLAUDE.md files and Model Context Protocol (MCP) servers: this page shows what each piece becomes in AlphaAgent Studio, so the same material runs as governed agents, knowledge graphs and connectors in your own AWS account.
What maps to what
| You have | It is | It becomes in AlphaAgent | Rule |
|---|---|---|---|
A SKILL.md that describes a role ("you are the desk's risk reviewer") | Behaviour | An agent: the skill body is the system prompt, the skill description is the agent description | One skill, one agent. Optimise Prompt once; activate with an environment. |
A SKILL.md that describes a procedure ("every morning do A, B, C") | Process | A workflow, built on the board or converted from one chat, with the agents as steps | A step that said "check with me" becomes an approval: a recorded decision by a named person, in the Inbox. |
| Scripts and binaries inside a skill | Tooling | A custom execution environment image, attached to the agents that need it | Plain Python with common packages runs on the prebuilt Python 3.12 environment. |
| Reference files inside a skill; Project knowledge files | Knowledge | A knowledge graph version built from a PDF; agents pin to it | One PDF of up to 32 pages per version, one topic per graph; agents pin to a version and are moved deliberately. |
Memories about the firm, the team and the method (MEMORY.md facts, CLAUDE.md rules) | Institutional memory | The team's doctrine graph, in the same PDF as the references (knowledge graphs); hard rules also go in the agent prompt | Number the sections so agents can cite them. |
| Memories about a person (preferences, tone, how they like output) | Personal memory | A "Working preferences" section in that person's own agent prompt | Personal preferences stay with the person; the firm's knowledge goes in the graph. |
MCP servers in claude_desktop_config.json or .mcp.json | Integrations | One MCP connector per server, attached to agents | A hosted server; credentials live in Secrets Manager. |
Sub-agents (Claude Code .claude/agents) | Delegation | More specialist agents, called by @ mention in chat or as workflow steps | One sub-agent, one agent, as for a role skill. |
| Hooks and permission rules | Control | The Governor, workflow approvals, read-only SQL connectors and personally identifiable information (PII) redaction | Platform controls that apply to every agent; see below. |
| Computer use, the local file system, a browser on the laptop | Local tooling | A script in a custom execution environment image, or a data connector to the system the browser reached | Cloud execution, sandboxed and audited; see below. |
Why some pieces change shape
Most rows in the table are a straight move. Four change shape on the way, and each is a design decision rather than a limit.
- Code runs in an execution environment in your AWS account, not on a laptop. AlphaAgent has been designed in this way because an agent that runs its code in a sandbox, with network access only through the connectors you attach, can run on a schedule while nobody is signed in, scale past one machine, and leave every action in the audit trail. A script a skill ran locally becomes a script in a custom environment image; a browser step becomes a connector to the system behind it.
- Integrations are hosted connectors, not processes on one machine. AlphaAgent has been designed in this way because a connector is available to every agent and every scheduled run, and its credentials live in Secrets Manager rather than in a configuration file. A server that runs locally today is hosted once, or replaced by a SQL, REST or AWS connector to the same system.
- Memory is split between the firm and the person. AlphaAgent has been designed in this way because what the firm knows belongs in a versioned knowledge graph that every agent cites by section, and how one person likes to work belongs to that person. Merging the two, which is what a single memory file does, is how one analyst's habits become the team's rules. Institutional memory goes into the doctrine graph; personal preferences go into the person's own agent prompt.
- Controls live in the platform, not in per-machine hook scripts. AlphaAgent has been designed in this way because a control that applies to every agent and cannot be edited away locally is the only kind a risk function can rely on: the Governor reviews every step against the grounded facts, an approval is a recorded decision by a named person, SQL connectors refuse writes at run time, and PII redaction is set by an administrator. A hook that did something outside those four has no counterpart; say so in the handover.
One principle runs through all of it: every resource is versioned. Agents, workflows, connectors and knowledge graphs each keep immutable versions; an agent pins to a connector version and a graph version, a workflow pins to agent versions, and a Library carries a chosen version to another deployment. AlphaAgent has been designed in this way because a skill file edited in place changes behaviour for everyone, silently, while a versioned resource changes it only when someone moves the pin.
How a migration runs
- Discovery. Agree the scope: which product (Claude Desktop, Claude Code or both), how many skills and what kind each is (role, procedure or tooling), what the memories hold (firm, team or person), which MCP servers and how they connect, who will use the result, and standard or governed.
- Collect. Gather the skills, agents and memory folders, every
CLAUDE.md, the.mcp.jsonorclaude_desktop_config.jsonwith secrets removed, Project files and the Claude Desktop memory export. Nothing else leaves the laptop. - Inventory and map. Put every item into the table above, one row per skill, memory set and server. Review it with the people who wrote the material and agree the agent names, the graph split and the deployment.
- Build in Studio, in this order. Connectors first (MCP, then any SQL, REST or AWS replacements): Studio drafts each connector's guide from its tool list, schema or OpenAPI specification, and you review and accept it. Then the environment, then the doctrine PDF and its graph. Then each agent: paste the skill body, let Optimise Prompt turn it into a production system prompt, add Working preferences, Configure the graph, connectors and environment, Save & Activate. Last, workflows for procedural skills: chat once, convert, add approvals, activate. Each piece takes minutes.
- Verify. Every agent's Agent Map shows the graph version, connectors and environment you chose; the graph version reads Ready; every connector has an accepted guide and a passed Test Connection where its type offers one. Run one chat turn per agent that exercises the skill and cites the doctrine.
- Share and hand over. Share the agents, workflows, connectors, environment and graph to a Library so other Studios pull them (Libraries and sharing). Hand over the mapping table as built and a note on what changed shape and why.
What you should see
Every migrated agent reads Active in Manage Agents, and its Agent Map shows the knowledge graph version, the connectors and the environment you chose. The doctrine graph's version reads Ready. Each MCP connector reads Active. One chat turn per agent answers in the skill's voice and cites a numbered section of the doctrine.