--- name: mindset-import-agent description: Use when moving an AI agent built in another framework or in plain code (OpenAI Agents SDK, LangGraph or LangChain, Claude Agent SDK, CrewAI, Amazon Bedrock Agents, Vercel AI SDK, or a hand-written loop) to Mindset (mindset.ai) through the mindset-admin MCP server. Reads the agent's code, maps its prompt, model, tools, handoffs, graph, guardrails and evals to Mindset, lists what won't come across, then keeps the result as files in the person's repo and applies them. metadata: title: Move an agent from another framework blurb: Reads an agent's code in another framework and rebuilds it on Mindset, kept as files in your repo. group: Mindset MCP order: 6 docs: move-an-agent-from-another-framework, keep-your-agents-in-your-code checked: 23edea589 updated: 2026-10-28 --- # Move an agent from another framework to Mindset When you finish, the agent runs on Mindset in the environment the person named, its configuration is files in their repo, and the person has agreed a list of everything that didn't come across. Mindset runs its own agent loop, so you rebuild the agent on Mindset. You don't wrap or host the old code. This skill is a pointer. The method for each piece lives in the server's `get_information` topics and in the other Mindset skills. Where they and this skill disagree, follow `get_information`. ## Mindset in brief Mindset is a hosted platform for building, running and governing AI agents. An **agent** is configuration, not code: a prompt, a model, and the resources it may use. Those resources are **scripts** (steps that must wait or happen in order), **functions** (fixed steps with one right answer), **widgets** and **connections** (the only way data enters or leaves). People manage all of it in the Studio, a web app, or through Mindset's MCP servers. ## Where you are building: host, org, environment Every Mindset call names three things. Get all three from the person before you write code or call a tool. Never guess or invent them. | Value | What it is | Where the person finds it | |---|---|---| | **Host** | The Mindset deployment their org lives on, for example `https://eu.mindset.ai` | The address bar when they're signed in to the Studio, or an agent's **Embed** tab | | **Org slug** | Their company's account. The org is the isolation boundary: members, model keys, settings and audit sit here, and one org can never see into another | An agent's **Embed** tab, or the address under **Settings → Systems → Connect an AI client** | | **Environment slug** | A named partition inside the org, such as Sandbox, Test or Production | An agent's **Embed** tab, or the same address. The **Environment** switcher in the Studio shows which one is current | How environments behave: - **Agents, scripts, functions, connections, triggers, schedules, conversations, runs and API keys each belong to exactly one environment** and can't see anything in another. - **Every org starts with one environment, Sandbox, whose slug is `original`.** A slug never changes, even when the environment is renamed. Use the slug, never the display name. - **Nothing copies between environments.** To promote a change from Test to Production, make the same change again in Production. - **Don't create an environment to hold your work.** Environments can't be deleted, and they're for stages such as Test and Production, not for projects. Work in the environment the person names. Create one only if the person asks you to. - **Members, model keys and org settings are shared by every environment.** Changing an org setting changes it everywhere. ## Credentials for building in Mindset: sign in, never a key You build inside Mindset through the **`mindset-admin` MCP server**. The person signs in with their own Mindset account in a browser, and they must be an org admin. There is no key or token, so never ask the person for one. - **The server address names one environment**: `/api/v1/orgs//envs//mcp`. Every call goes to that environment unless the tool call passes `envSlug` to point that one call at another environment. Org-level tools refuse an `envSlug`. - **No tool takes a secret value.** When a connection needs a credential, call `request_capture`. It returns a reference and a capture URL. Give the person the URL to open and paste the value into themselves, then use the reference. Capture links expire after 15 minutes. For a system that signs in with OAuth, `authorize_connection` returns a sign-in link the person opens the same way, and it expires after 10 minutes. If a link has expired, request a new one. Never ask the person to paste a credential into the conversation, even if they offer. - **Errors come back structured.** Read `code` and `context` and act on them. Don't retry blind. ## Before you start This skill works through the `mindset-admin` MCP server. Check that its tools (for example `get_information`) are available to you. If they aren't, set the server up first, following the `mindset-mcp` skill or https://docs.mindset.ai/docs/work-from-claude-code.md, then come back here. Call `get_information` with no arguments for the platform's own topic index. Its guidance is current for the platform you're connected to. Where it and this skill disagree, follow `get_information`. ## Read first 1. `get_information` with `topic='what-is-this-platform'`, for what connections, functions, scripts and agents are. 2. `get_information` with `topic='choosing-what-to-build'`, before you map anything. 3. `get_information` with `topic='boundaries'`, so a gap is reported plainly rather than built around. 4. `find_examples` with the agent's job in the person's words and no `resource_type`. ## Ask the person for - Where the agent's code is, in full: every file that defines its prompt, tools, handoffs and graph. - Which environment to build in. Default to the one the server address names. - Where in the repo the Mindset files go. Suggest `agents/`. - Its evals or test questions, if it has any. ## Step 1: take an inventory Read the code and list each part below, with the file and line it comes from. | Part | Where it usually is | |---|---| | Prompt | OpenAI Agents SDK `Agent(instructions=...)`. LangGraph or LangChain system message or `prompt`. Claude Agent SDK `system_prompt`, `CLAUDE.md` and skills. CrewAI `role`, `goal`, `backstory`. Bedrock Agents `instruction`. Vercel AI SDK `system` | | Model | The model name passed to the agent or the model call | | Tools | `@tool` or `function_tool` functions, MCP servers, Bedrock action groups and their OpenAPI schema, the `tools` object | | Handoffs | `handoffs=`, subagents, a CrewAI crew's agents and process, graph nodes that are other agents | | Order and waits | Graph edges, `interrupt()`, approval steps, a sequential process | | Retrieval | Vector stores, retrievers, Bedrock knowledge bases | | Guardrails | Input and output guardrails, validators, refusal rules | | Evals | Test sets, eval scripts, LangSmith datasets | For each tool, record what it does: calls an outside API, is an MCP server, or runs logic in the process (computes, loops, reshapes data, reads local files). ## Step 2: map each part | Part | On Mindset | |---|---| | Prompt | The five prompt fields, at most 2,000 characters each. Condense, and keep what you cut for the gaps list | | Model | `llmModel`, from the models the org can run | | A tool that calls an API | An HTTP API connection with one operation per tool. Read `authoring:connection:api` | | An MCP server | An MCP server connection. Read `authoring:connection:mcp`. Only remote servers can be connected | | A tool that computes, loops or reshapes | A function. Read `authoring:function` | | Handoffs | Separate agents, on the lead agent's `agents` resources | | An ordered stretch, a wait or an approval | A script for that stretch only. Read `authoring:script` and `authoring:script:resources` | | Retrieval | A knowledge base connection, to a search server that speaks MCP and exposes one tool, `rag_search`. Mindset doesn't index documents itself | | Guardrails | `policyRules` for behavior. A rule that must hold every time becomes a script gate, a function, or an operation the agent doesn't hold | | Evals | Behavior tests. Read `behaviour-testing` | Most agents need no script. Use `choosing-what-to-build` for every part you're unsure of. ## Step 3: list what won't come across, and wait Before you build anything, give the person one list: - Tool code that runs in their process and no function can replace. It needs to sit behind an API or a remote MCP server first. - Local files, local (stdio) MCP servers, HTTP APIs that need an OAuth sign-in, and a vector store with no MCP search server in front of it. - Behavior that depended on changing the agent loop. - Prompt text you condensed, word for word. - Past traces and memory, which stay where they are. Wait for the person to agree it. Build nothing until they do. ## Step 4: write the files Write the agent into the repo before you apply it. One folder per agent, connections shared: - `agents/connections/.json`: each connection and its operations, with no credential. - `agents//agent.json`: handle, name, `llmModel`, availability, resources and a fixed `idempotencyKey`. - `agents//prompt/.md`: one file per prompt field. - `agents//script.json`, `functions/.json`, `widgets/.json`: each the exact input `create_resource` takes. Leave the old agent's code where it is. ## Step 5: apply Build each piece with its own skill, from the files: - Connections: the `mindset-connect` skill. Credentials go in through `request_capture`, entered by the person. - Functions: the `mindset-function` skill. - The agent, its resources and its script: the `mindset-build-agent` skill, with the `idempotencyKey` from `agent.json`. A retry uses the same key. - If the org has turned off "Turn on connections that change other systems automatically" (Settings → Systems), each new write operation waits for a person's approval in the Studio. Tell the person which ones. ## Step 6: test Turn each eval question into a behavior test, and run the test parameters of any script and function. Use the `mindset-test-agent` skill. Compare the answers with the old agent's on the same questions. ## Step 7: read back Read the live agent, its resources, script and connections back with `get_agent`, `get_resource` and `agent_config_admin` verb `describe_resources`, and save the result as `agents//live.json`. Add a test to the repo that fails when the files and `live.json` differ, so a change made in the files but never applied fails the build. ## Rules - Never paste the old agent's API keys or tokens anywhere. Every credential goes in through `request_capture`. - Never turn on `hub`, `embed` or `api` availability yourself. The person decides. - Don't create an environment for this work. - Report anything on the platform you couldn't make work with `platform_issue`. ## Read more - https://docs.mindset.ai/docs/move-an-agent-from-another-framework.md: read for the mapping and what doesn't come across, as the person sees it. - https://docs.mindset.ai/docs/keep-your-agents-in-your-code.md: read for the repo layout and how a change goes live. - https://docs.mindset.ai/docs/choose-what-to-build.md: read when a part could be prompt text, a script or a function. ## Done means - The person agreed the list of what didn't come across. - The agent's files are in the repo, and the live agent matches them. - Its behavior tests pass on the old agent's eval questions. - You told the person which writes wait for approval and which surfaces are still off.