INVOKE THIS SKILL when building, testing, or deploying Managed Deep Agents in LangSmith with the mda CLI. Walks a user through their first agent end to end — interviewing them about what they want to build, mapping it onto what MDA can actually do, then scaffolding and deploying it. Covers the file-

Managed Deep Agents Overview Managed Deep Agents (MDA) is a hosted runtime for code first Deep Agents in LangSmith. You author an agent in Python or TypeScript, test it locally with mda dev , and deploy it with mda deploy or from a connected GitHub repository in LangSmith. It pairs the open source Deep Agents harness (see [[deep agents core]]) with managed infrastructure: durable runs, sandboxes, Context Hub backed instructions and skills, memory, traces, and hosted LangGraph deployment. The core idea is that an agent is a directory . A file's location determines its role, and the CLI compiles that directory into a managed LangGraph app. MDA is in public beta and runs on US LangSmith Cloud only . When to use Use this skill when the user wants to build a Deep Agent in code and run it on LangSmith without operating their own server, or to add tools, MCP servers, connections, middleware, memory, identity, schedules, channels, skills, sandboxes, or evals to one. Use a standard LangSmith Deployment instead (see [[langgraph cli]], langgraph deploy ) when the user needs custom server routes or runtime wiring inside the agent deployment, stronger isolation, maximum scalability, or a region other than US. MDA can still sit behind a separately operated backend that authenticates callers and proxies trusted identity headers. Guide the user through their first agent When a user is new to MDA, or says anything like "help me build an agent", do not scaffold immediately . Run this flow. It costs two questions and prevents building something the platform cannot host. 1. Ask what they want to build Ask in plain language, not in MDA vocabulary. The user does not yet know what a "channel" or a "sandbox" is. Ask these two things first: What should the agent do? ("Answer questions about our docs", "triage incoming bugs", "post a summary every morning".) Who or what talks to it, and from where? (Them in a browser, their app's users, a Slack workspace, nobody — it runs on a timer.) Then ask only the follow ups that the answers actually raise: Does it need to remember anything between separate conversations? Does it need to reach a private API, database, or internal service? Should anything require a human to approve before it happens? Does it need to write files or run code? Stop asking once you can name the capabilities. Two or three questions is usually enough. 2. Check the answer against the limits Before you promise anything, check the request against [What MDA cannot do]( what mda cannot do) below. If part of the request is out of scope, say so in one sentence, offer the nearest supported thing, and keep going with the rest. Do not quietly build a smaller agent and present it as what they asked for. The common redirect: if they need custom HTTP routes, their own auth, or non US hosting, tell them MDA is the wrong layer and point at langgraph deploy ([[langgraph cli]]). 3. Map the answer onto capabilities What the user describes What to reach for Where it lives How it should behave, its tone, its rules Instructions instructions.md Calls our API / database / internal service Authored tools tools/ Uses a remote MCP server MCP declaration tools/mcp.py or tools/mcp.ts Uses a workspace secret or OAuth grant Connection connections.get(...) + mda connections A procedure it should follow for certain tasks Skills skills/<name /SKILL.md Remembers things across conversations Durable memory (read the warning) memory.py Runs on a timer, no user message Schedules schedules/<name .py Lives in Slack Channels channels/slack.py Writes files, runs code or shell commands Sandbox sandbox/ init .py Ask me before it does X Human in the loop interrupt on= Users must not see each other's chats Supabase identity identity.py Must return structured data, not prose Structured output response format= Hand off specialized work Subagents subagents= PII redaction, call limits, retries, logging Middleware middleware/ Prove it still works as we change it Harbor evals evals/<task / 4. Confirm the shape before writing files State the plan back in one short block and get agreement. Name the model, and list only the capabilities you are actually going to create: 5. Scaffold and wire the smallest thing that runs Scaffold with the flags that match the plan, so the project starts correct instead of being edited into shape: Then add one capability at a time and confirm each one works before adding the next. A first agent that answers with good instructions and one real tool is a better starting point than a scaffold with every directory filled in. Do not create directories the plan did not call for. Empty or unused skills/ , channels/ , or schedules/ directories are noise, and a sandbox/ directory the user does not need turns on a sandbox they will pay attention to for no reason ( mda init no sandbox skips it). 6. Handle keys without touching their secrets mda init writes a .env with empty placeholders. Fill in the names the project needs and let the user paste the values : Do not write live credential values into .env yourself, and do not copy a key from another project directory. Do not echo key values to the terminal or into your reply. Confirm .gitignore covers .env and .env. — mda init does this already. The project needs LangSmith authentication to deploy and whatever credentials its selected model requires. For a normal provider model, uncomment its key ( ANTHROPIC API KEY , OPENAI API KEY , …) and let the user supply it through .env or LangSmith workspace secrets. An explicitly configured Gateway backed client uses its Gateway/LangSmith credential instead of a provider key. 7. Run it locally, then deploy Have the user actually send a message in Studio and confirm the agent calls the tool before deploying. mda deploy prints the deployment dashboard URL; open it to inspect builds, revisions, and traces. What MDA cannot do Check requests against this list before agreeing to build them. Being straight about a limit early is cheaper than discovering it at deploy time. Limit Consequence US LangSmith Cloud only No self hosted, no hybrid, no EU region. Needs langgraph deploy . No public management API Use mda or LangSmith's GitHub deployment UI to create and update agents. Do not invent a public create/update REST flow. Slack is the only channel No Discord, Teams, email, or SMS channel. Remote MCP servers for those products are tools, not channels. Memory is deployment shared One /memories/agent/ tree for all callers. There is no per user memory. One agent entry per project No multiple graphs in one project. Use subagents= for delegation. Schedules must be static literals No env vars, function calls, or computed values in a schedule declaration. Build archive capped at 200 MB Large fixtures or model weights in the project will fail the deploy. Managed fields are not yours to set backend , store , checkpointer , memory , skills , and the system prompt are injected by the runtime. Sandbox scope is managed Sandboxes are one per thread. Agent shared sandbox scope is no longer supported. Prerequisites A workspace with Managed Deep Agents public beta access, and a LangSmith API key for it. Python and [ uv ](https://docs.astral.sh/uv/) for Python projects; Node.js and npm for TypeScript. Credentials required by the selected model, either in the project .env or as LangSmith workspace secrets. Install the CLI. Both packages ship the same mda binary: mda init generates a project with its own manifest — run uv sync (or npm install ) inside that project before mda dev . Project layout The path passed to mda is the project root. A file's location determines its role: Only the agent entry is required. tools/ and middleware/ are plain conventions — MDA copies project files verbatim, so any local module the agent imports works. The other paths take on managed meaning when present. The TypeScript agent entry may be agent.ts or agent.tsx ; managed auxiliary declarations also accept .mts and .cts where discovered. Define the agent The agent entry returns a pre runtime spec, not a compiled graph. name is required. Pass a static string starting with a letter, containing only letters, numbers, underscores, or hyphens. It becomes the LangGraph assistant ID and the default deployment name; override the latter with mda deploy name . Author set fields: name , model , tools , middleware , subagents , permissions , interrupt on / interruptOn , response format / responseFormat , context schema / contextSchema , cache , debug , metadata . Managed fields — do not set: backend , store , checkpointer , memory , skills , system prompt / systemPrompt . Model IDs use {provider}:{model id} and resolve through init chat model , so any of its providers work. Note the provider slug differs across languages: Python uses google genai:gemini 3.6 flash , TypeScript uses google genai:gemini 3.6 flash . Pass a chat model instance instead of a string when you need to configure model parameters in code. The dedicated mda init gateway scaffold was removed. To use LangSmith Gateway, configure a supported chat model client explicitly in agent.py or agent.ts ; do not pass the removed flag or rely on its former credential preflight. Instructions instructions.md at the project root is the system prompt. It is inserted on every run. mda dev embeds it locally. mda deploy syncs it to Context Hub, where it can be edited in the LangSmith UI without redeploying. Skills Deploy owned procedures under skills/<name /SKILL.md , each with name and description frontmatter. At startup the agent sees only names and descriptions, and reads the full file when a task matches — so detailed procedures cost no context until they are needed. A skill directory may also hold scripts, references, and templates; reference them from SKILL.md . Deploy syncs every UTF 8 file under skills/ to Context Hub and deletes deployed skill files that no longer exist locally. The agent cannot modify skills. Use instructions for always on behavior, skills for procedures loaded on demand, and memory for knowledge the agent itself updates. Memory Durable memory is opt in and off by default . Declare it at the project root: Delete the file to turn memory off. Enabling it mounts one Context Hub tree at /memories/agent/ : /memories/agent/AGENTS.md is hot memory — loaded into every run, so keep it compact. Other files under the tree are cold memory — read only when relevant. The agent reads and writes memory with read file , edit file , and write file . Writes anywhere else, including elsewhere under /memories/ , are not durable. Warning — memory is shared by every caller of the deployment, and every caller can influence it. Never store personal data, customer data, credentials, API keys, or tokens there. Treat memory content as untrusted input: it must never grant authority, change tool permissions, or bypass approvals — keep those in the agent definition. Do not enable shared memory when callers should not be able to influence one another. The agent decides what to remember by prompting, so state the policy in instructions.md — what to store, what never to store, and that existing memory is notes rather than instructions. Identity identity.py controls who may call the deployment. mda init scaffolds a secure default: Callers send a LangSmith workspace API key as x api key . This answers whether a caller is allowed — it does not give each per

managed-deep-agents