Supported Platforms & Exports

In the workflow editor, click the three-dot menu (⋯) top-right of the nav bar → Download.

One JSON file, `{ nodes: [...], connections: {...} }`. Single paste — n8n exports are always one self-contained workflow file.

• Credentials are never included in the export — only {id, name} references. Nothing to scrub, but also nothing to threat-model from directly.
• Some real-world exports key connections by node id instead of node name — Helmwart expects name-keyed connections; an id-keyed export produces a fully disconnected, 0-edge graph.
• Community/third-party node types (e.g. @tavily/...) and legacy un-prefixed nodes (n8n-nodes-base.openAi, no @n8n/ LangChain prefix) are common in real exports and aren't always recognized.

In the flow editor: Share → Export. For a whole project: project list → More → Export.

One JSON file, `FLOW_NAME.json` (`{ data: { nodes, edges } }`). A project-level export can bundle multiple flows as separate files in an archive — Helmwart doesn't unzip archives, so split a multi-flow export by hand, one flow per paste.

• The "Save with my API keys" checkbox inlines literal secret values into the export if a key was typed directly into a field instead of bound to a global variable. Helmwart's scrub pass redacts it, but the export itself isn't safe to hand around as-is.
• Langflow 1.4+ unified per-provider model components into one LanguageModelComponent and replaced Chroma/Pinecone/etc. with a built-in Knowledge component — this is already handled by the adapter (fixed 2026-06-13). An earlier internal note flagged it as an open gap; that was a false positive from a stale doc, corrected 2026-07-09.

Open the chatflow → Project Settings (gear icon) on the canvas → Export Chatflow.

One JSON file, top-level `{ nodes, edges }` (no `data` wrapper — that's the dialect-sniff signal that tells it apart from Langflow).

• Credentials are stripped on export by design — Flowise doesn't leak inline secrets the way an unbound Langflow field can.
• Bulk "export all chatflows" was removed from the product; maintainers now point users at a full DB backup instead, so per-chatflow single-file export is the only path.
• Community package/tool nodes may not map to a known capability.

App's Studio page → app menu → Export DSL (also an "Export DSL" button top-left of the editor).

One YAML file (`version`, `kind: app`, `app`, `workflow.graph` or `model_config`, optional `dependencies[]`). Single paste.

• Third-party tool API keys are excluded from export by design. Secret-type environment variables trigger an explicit "include secrets?" prompt — some exports do carry live secrets if the user opts in; Helmwart scrubs regardless.
• Nodes inside iteration/loop containers link via parentId/start_node_id, not DSL edges — the adapter currently renders them as orphans.
• Pre-0.3 community exports may omit version/kind entirely — detected at lower confidence (0.80) rather than rejected.
• Marketplace plugin dependencies (dependencies[].type: marketplace) are real supply-chain surface the adapter doesn't yet render as a node — and that warning currently only fires on workflow-mode exports, not agent-chat mode.

1. In the Agent Development Environment (ADE): Export Agent (downloads the .af file directly).
2. Or in code: client.agents.export_file(agent_id=...) (Python/TS SDK), or the REST export endpoint.

One JSON file/string. AgentFileSchema legitimately holds agents[], groups[], blocks[], files[], sources[], tools[], mcp_servers[] — a single .af export can contain multiple agents/groups; that's normal for the format.

• Double-encoding quirk: every official Letta example script does json.dump(client.agents.export_file(...), f), but export_file() already returns a JSON string — dumping it again re-serializes it, so real .af files on disk commonly have one extra JSON-string layer. The adapter unwraps this automatically; a correctly single-encoded file (the ADE's own download button) also works.
• Secrets are exported as null, not omitted — never assume a .af file carries live credentials; reconfigure credentials on import regardless.
• A real community .af file can be several MB — over Helmwart's 2 MB paste cap — even though the adapter itself parses it in well under a second once it gets there.

1. No export step — copy the file that already exists.
2. Claude Desktop: ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) / %APPDATA%\Claude\claude_desktop_config.json (Windows).
3. Claude Code: .mcp.json at the repo root. VS Code (servers or nested mcp.servers) and Cursor (.cursor/mcp.json) follow the same mcpServers/servers shape.

The whole JSON file, single paste.

• env values are live secrets — Helmwart redacts the values but keeps the key names (the name itself is a threat signal, e.g. an OPENAI_API_KEY sitting on a tool node).
• VS Code's ${input:...} secret-placeholder syntax reads as a plain string and isn't specially flagged.
• A secret passed as a positional CLI flag (e.g. --api-key llx-…) with a vendor prefix Helmwart doesn't recognize (only sk-/ghp_/AKIA/xoxb-… are hardcoded) isn't scrubbed today — a real gap, most visible on MCP servers that take credentials via CLI args rather than env.

Fetch https://<agent-domain>/.well-known/agent-card.json — an RFC 8615 well-known URI, no export tool; the peer agent already serves this file if it speaks A2A.

One JSON file (the AgentCard).

• Cards come in two generations: pre-1.0 (url + preferredTransport + additionalInterfaces[]) and 1.0+ (supportedInterfaces[], each with url/protocolBinding/protocolVersion). The ecosystem migrates slowly, so real cards in the wild are a genuine mix — the adapter reads both.
• v1.0 adds optional cryptographically Signed Agent Cards — not parsed for content, but their presence is itself a trust signal worth noting.
• Detection currently hard-requires a skills[] array. A real, current (v1.0.1) production agent card that declares its tool catalog via tools[]/mcp_endpoints[] instead — a real, observed convention — is not recognized today and shows "Format not recognized." Known gap, tracked.

1. adk create <app_name> scaffolds a Python project — the resulting agent.py (from google.adk.agents.llm_agent import Agent; root_agent = Agent(...)) is the artifact, no separate export step.
2. No-code variant: adk create --type=config <app_name> generates a declarative root_agent.yaml instead (the real generated filename, not agent.yaml).

agent.py in full, or root_agent.yaml.

• sub_agents[].config_path references point at other files by path and aren't auto-resolved by the adapter — each referenced sub-agent gets an unresolved-file-ref peer-agent placeholder unless its file is also pasted.
• Whether a `---`-joined multi-file paste works here the way it does for CrewAI hasn't been confirmed — don't assume it.

1. crewai create crew <name> scaffolds crew.jsonc + agents/<role>.jsonc — the current default.
2. crewai create crew <name> --classic scaffolds the older config/agents.yaml + config/tasks.yaml + crew.py layout instead.

JSONC path: crew.jsonc + each agents/<role>.jsonc, concatenated with ---. Classic path: agents.yaml (+ optional tasks.yaml/crew.py), same --- convention for multiple files.

• JSONC agent docs carry no name field — the agent is identified by its filename stem (snake_case(role)). A crew.jsonc reference with no matching pasted agent doc becomes a stub node with a warning rather than being silently dropped.
• If the role text and the file's snake-case stem diverge (or the role exceeds ~30 characters, past where the wizard truncates it), the name-matching heuristic can produce a duplicate "ghost" agent — guardrail/HITL nodes then attach to the ghost while the real agent is left disconnected. Reproduced 3 ways against real CLI output; tracked.
• On the classic YAML path, prior corpus research found roughly 60% of the real threat surface — tools, process type, manager agent, memory, knowledge sources — lives only in crew.py, invisible if you paste just agents.yaml/tasks.yaml. 4 of 5 real crews sampled had zero YAML-visible tools.

1. print(json.dumps(graph.get_graph().to_json(), indent=2)) for JSON.
2. Or print(graph.get_graph().draw_mermaid()) for Mermaid text (not the PNG variant).

The JSON text {nodes:[...], edges:[...]}, or the raw Mermaid flowchart text.

• The dict-repr trap: to_json() returns a Python dict; print()-ing it without json.dumps() around it prints Python's single-quoted repr, which is not valid JSON. This is exactly the naive path a new user takes.
• Topology-only fidelity: neither export format carries tools, state schema, checkpointer/store backend, recursion_limit, or the model id — everything past edge topology is inferred from node names, and Helmwart says so plainly on every import.
• interrupt_before/interrupt_after metadata is written at graph-build time but is stripped before to_json() serializes it — neither documented export command actually surfaces interrupts on its own. This is a real gap in what LangGraph currently lets you export, not just an adapter limitation.
• Marking a tool node with interrupt_before currently overwrites its danger/tool classification with a plain HITL-gate node, and a conditional fan-out from START can draw a hierarchy edge between two branches that don't actually connect. Both are tracked adapter bugs, not export gaps.
• Subgraph nodes are namespaced parent:child — expected, not a bug.
• LangGraph JS's toJSON() parity with Python's to_json() hasn't been confirmed against any LangGraph.js doc — don't assume JS users get the same shape.

config = component.dump_component(); print(config.model_dump_json()) — works on any single agent or a whole team object.

JSON text, {provider, component_type, version, component_version, description, config}; for a team, config.participants[] holds the nested agent components.

• Two structurally different shapes exist: COMPONENT (v0.4+, the dump_component() output above) vs. CLASSIC (v0.2, an OAI_CONFIG_LIST array or {config_list:[...]} — a model roster with no graph topology). Pasting the classic shape gets a flat model list, not a graph.
• UserProxyAgent.input_func (the real human-in-the-loop hook) is an async callable and frequently isn't serializable — when it's null/absent (the common case), the resulting gate is functionally inert but looks identical on the canvas to a real one. Helmwart defaults it to no approval authority and flags it as an assumption for exactly this reason.
• SelectorGroupChat.selector_func (custom routing/safety logic) is explicitly documented by AutoGen as dropped on serialization — invisible to the import no matter what.
• AutoGen is now confirmed in Microsoft's maintenance mode ("will not receive new features or enhancements... new users should start with Microsoft Agent Framework," per the live repo README). Latest release stays at v0.7.5, bug-fix-only since Sept 2025.

1. Paste the .py file(s) containing Agent(...) constructor calls directly — no export step.
2. Legacy: the Assistants API JSON object (GET /assistants/{id}, or List Assistants for a bundle).

The .py file(s) — including any separate files that define handoffs=, guardrail functions (@input_guardrail/@output_guardrail), or hosted tools. Or the legacy Assistants API JSON object.

• Multi-file systems: handoffs=[other_module.specialist_agent] won't resolve if only one file is pasted — no cross-file resolution.
• ShellTool, ImageGenerationTool, HostedMCPTool, and mcp_servers= aren't yet covered by the tool classifier — they fall through to "unknown" or are silently dropped. A remote-MCP-wired agent currently imports with zero tools, zero edges, and zero warnings for that surface — a real gap that understates RCE/MCP exposure.
• Regex-based parsing misses dynamically-assembled tool/handoff lists (tools=get_tools()).
• The guardrail-to-node mapping is currently optimistic — it maps to a human-approval gate even when the guardrail is fully automated, independent of export mechanics.
• Legacy Assistants API retires 2026-08-26 (Azure OpenAI's Assistants API, same date) — after that date the API stops working entirely, not just for new usage.

Paste the .py file(s) with Agent(...) calls, plus any Swarm(...)/GraphBuilder() multi-agent wiring and @tool-decorated functions that live in separate modules.

The .py source directly — there is nothing else to export.

• No canonical export/serialization format exists for Strands — source code remains the only definition format, confirmed against current docs.
• Swarm/GraphBuilder setups often span multiple files, one per specialist agent — pasting only the orchestrator file misses peers.
• Dangerous built-ins (python_repl, shell, use_aws, mcp_client) are plain string references inside tools=[...] — if imported under an alias or built by a helper function, the regex parser won't resolve them, understating danger.
• No danger-level flag on python_repl/shell today, no BedrockModel guardrail_id detection, and no explicit warning on the dynamic mcp_client tool.

1. Paste the declarative agent/prompt-function YAML (ADR-0070 schema — type: chat_completion_agent | openai_assistant | azureai_agent | foundry_agent).
2. Or the .cs/.py/.java source with Kernel.CreateBuilder(), plugin registration, and agent construction.

The YAML or source file directly.

• SK's primary security control plane — Filters (IFunctionInvocationFilter, IPromptRenderFilter, IAutoFunctionInvocationFilter) — is code-only, not declarative, and isn't parsed or represented at all. A pasted system with real filter-based guardrails looks unguarded on the canvas.
• Multi-file plugin registration (AddFromType<T> across separate plugin classes) won't resolve unless every relevant file is pasted.
• execution_settings.function_choice_behavior scoping (which plugins an agent can actually call) is silently ignored — can't distinguish a well-scoped agent from one with every plugin exposed.
• Semantic Kernel is confirmed transitioning to maintenance mode behind Microsoft Agent Framework, per Microsoft's own migration guide; SK keeps bug-fix/security support for at least a year post-GA (roughly through April 2027). No fixed SK sunset date is published beyond that.

Paste the .py file(s) using from agent_framework import ..., or the .cs file(s) using Microsoft.Agents.AI;.

The source file directly. This adapter recognizes the format but doesn't build a graph from it yet — you'll get an honest "detected, no parser yet" message and model the system by hand for now.

• A newer declarative YAML/JSON authoring format (agent-framework-declarative on PyPI / Microsoft.Agents.AI.Declarative on NuGet, documented since 2026-05-22) exists and isn't recognized by this adapter's source-code-only detect signals.
• More importantly: that same declarative YAML (kind: Prompt) is currently misdetected as an Azure AI Foundry agent instead — a confident, unwarned match with the model id left as a literal unresolved macro (e.g. =Env.AZURE_OPENAI_MODEL). If you authored your agent declaratively, check the detected platform label before importing; a wrong-vendor-labeled graph is a known, tracked bug, not a hypothetical.

1. Paste the .ts file that constructs the agent — `new ToolLoopAgent({ model, instructions, tools })`, or the `generateText`/`streamText` call that carries the tools.
2. Paste the `tool({ ... })` definitions alongside it, and the route handler if the agent is served to a browser.

The TypeScript source directly — an AI SDK app has no export format.

• A tool imported from another file appears on the canvas with no capabilities and a warning; capabilities are read from the `execute` body (and one level of helper it calls), never from the tool name.
• An MCP client hands the agent whatever the server advertises at runtime, so the whole server appears as one tool bus rather than as individual tools.
• `Agent` and `Experimental_Agent` are deprecated aliases of `ToolLoopAgent` and all three are accepted — but `new Agent()` imported from `@mastra/core` is a different framework and is routed to the Mastra adapter instead.

1. Paste the files under src/mastra: the agent file, the `createTool` definitions it imports, any `createWorkflow` chain, and the `MCPClient` config.
2. Include src/mastra/index.ts if you have one — the `new Mastra({ agents })` registry is what serves each agent over HTTP.

The TypeScript source directly — a Mastra project has no export format.

• Tools, workflows and sub-agents defined in files you did not paste show on the canvas with no capabilities and a warning.
• Each MCP server in `new MCPClient({ servers })` becomes its own tool bus, with its transport read from `url:` (http/sse) or `command:` (stdio); the tools it advertises are only known at runtime.
• An agent registered on `new Mastra({ agents })` is served at /api/agents/<id> by `mastra dev` and `mastra start`, so it is drawn with an untrusted external caller. Remove that edge if your deployment fronts it with its own authentication.

1. Paste the .py file with the `Workflow` subclass and its `@step` methods, or the `FunctionAgent` / `AgentWorkflow` construction.
2. Paste the tool functions and the index/query-engine setup alongside it.

The Python source directly — there is nothing else to export.

• The step graph lives entirely in type hints: a step's input event is the annotation on its event parameter and its outputs are its return annotation. A step with no return annotation cannot be wired to whatever consumes its event.
• A `Workflow` with no LLM anywhere in it is imported as a plain pipeline with no agent node — that is deliberate, not a miss: firing agent rules on a pipeline that never calls a model would be inventing a threat surface.
• `llama_index.core.workflow` is a re-export of the standalone `workflows` package (`pip install llama-index-workflows`), and `llama_agents.workflows` is a third alias for the same objects — all three import paths are accepted.

Paste the .py file that builds the agent: the `Agent(...)`, `Team(...)` or `Workflow(...)` construction plus the toolkits, `Knowledge` and `db` objects it references.

The Python source directly — there is nothing else to export.

• Agno passes the model identifier as `id=` inside the model class — `model=OpenAIChat(id="gpt-4o")`. A file that builds its model in another module imports with no model node.
• Toolkits imported from elsewhere appear with no capabilities and a warning rather than being dropped.
• Both the v2 spelling (`db=SqliteDb(...)`, `Knowledge(...)`, `AgentOS`) and the v1 spelling (`storage=...`, `*KnowledgeBase`, `Playground`) are read, since plenty of real code is still on 1.x.

1. Hosted agent.yaml: VS Code command palette → "Foundry Toolkit: Create a New Hosted Agent" (or open an existing hosted-agent project) — scaffolds agent/agent.yaml + Dockerfile + main.py locally.
2. Workflow YAML: Foundry portal → project → Build tab → YAML button → Open in VS Code for Web.
3. Classic Assistants / connected-agent: the Azure OpenAI Assistants REST API (GET /assistants/{id}, or List Assistants for a bundle), or the classic Foundry portal.

A single agent.yaml (hosted or declarative-Prompt), a workflow YAML export, a classic assistant JSON object, or a List-Assistants bundle ({object:"list", data:[...]}).

• Hosted agents' tools/instructions run inside the container image — not in agent.yaml at all. The exported manifest is honestly incomplete for this shape; that's an inherent visibility gap, not a parsing bug.
• "Connected Agents" has already been removed from the current Foundry Agent Service.
• Workflow YAML (kind: workflow) exists in the Foundry portal, but this adapter doesn't actually detect it today — a real workflow export shows "Format not recognized" instead of the intended honest "not supported yet" message. One-line fix pending; tracked.
• The plain single (kind: Prompt) agent export path has no confirmed docs page showing where a user clicks to get it — the schema itself is verified, the click-path is not.
• A declarative Microsoft Agent Framework export (kind: Prompt, model id as a literal macro) is currently misdetected as this platform instead of Agent Framework — see the Agent Framework entry above.
• Workflows retire 2026-12-01 (successor: Microsoft Agent Framework). Classic Assistants JSON retires 2026-08-26 and stops working entirely after that date, not just for new resources.

1. aws bedrock-agent get-agent --agent-id <value> — response wraps the agent body in {"agent": {...}}.
2. aws bedrock-agent list-agent-action-groups --agent-id <value> --agent-version <DRAFT|1-99999>
3. aws bedrock-agent list-agent-knowledge-bases --agent-id <value> --agent-version <DRAFT|1-99999>
4. No-CLI alternative: CloudFormation IaC generator — start a resource scan → Templates → Create template → Start from a new template → filter by AWS::Bedrock::Agent, add the related AWS::Bedrock::KnowledgeBase/AWS::Bedrock::Guardrail resources → generate the template.

The get-agent JSON alone for a reliable import today (see gotchas), or a CloudFormation template for AWS::Bedrock::Agent.

• --agent-version is required on both list-* calls and must match the version described by the paired get-agent body (DRAFT vs. a numbered version), or the action groups/knowledge bases won't line up.
• The documented multi-doc paste (get-agent + list-agent-action-groups/knowledge-bases, concatenated with ---) is not actually merged by the parser today — pasting them together currently fails with a parse error. Paste the get-agent JSON alone until this is fixed; tracked.
• list-agent-action-groups never returns parentActionGroupSignature, so built-in CodeInterpreter/Bash/Computer RCE classification can't fire from the documented call sequence — a data-availability gap, the classifier logic itself is correct.
• The "supervisor + full collaborator bodies" bundle shape ({supervisorAgent, collaboratorAgents, associateCollaboratorCalls}) is a Helmwart-invented convention, not a real AWS artifact — AWS never returns a supervisor plus full collaborator bodies from one call; real multi-agent wiring happens via alias-ARN-only AssociateAgentCollaborator calls. There's no single AWS command that produces this envelope.
• Existing CloudFormation stacks keep working indefinitely; only accounts with no prior Bedrock Agents activity are blocked from creating new agents after the cutoff below.
• Bedrock Agents Classic blocks CreateAgent/InvokeInlineAgent for accounts with no Bedrock Agents activity in the prior 12 months, starting 2026-07-30 — existing active agents/accounts are unaffected, no forced migration deadline. AWS's stated successor for new work is AgentCore.