The Developer's Rosetta Stone.
When you switch AI platforms, the model is the easy part. The friction is vocabulary — the same capability wearing a different name in every stack.
Every team that adopts a second AI platform rediscovers the same truth. The hard part of the migration is almost never the model, the latency, or even the pricing. It's the dictionary. The thing you call a tool in one stack is a function in another, a skill in a third, and a connector in a fourth. The "memory" you configured in one console is a "knowledge base" in the next and a "retrieval strategy" in the one after that. You already understand the concepts. You're just being forced to relearn their names — and that relearning is where weeks quietly disappear.
This guide is built for developers, systems architects, and technical builders who move between vendors and need to translate fast. It lays down the canonical nomenclature for each platform, then puts the players in each category side by side so you can map your existing mental model onto a new vendor's vocabulary and start building the same afternoon.
Switching platforms isn't learning new capabilities. It's learning new names for capabilities you already have. This is the dictionary that collapses that translation cost to near zero.
The landscape sorts into four categories. Enterprise agent runtimes host and govern autonomous agents at scale. Agentic coding environments write and run code inside your repositories. Data-native app builders bridge enterprise data lakes to interactive applications. And the skills & extension layer packages domain workflows so a generalist model becomes a specialist. Each section below opens with a quick-reference map, then goes in-depth on where the vendors genuinely diverge.
Enterprise Agent Platforms & Cloud Runtimes
These platforms exist to host, execute, secure, and scale autonomous agents grounded in enterprise data. They look wildly different in their consoles and share almost no terminology — but structurally they converge on the same five building blocks.
1 · Developer loop & local prototyping
Leans on Agent Studio — a visual web console — for fast prototyping, then transitions into code with the model-agnostic ADK. Console-first, code-second.
Ships a state-of-the-art CLI (@aws/agentcore). Running agentcore dev spins up a local hot-reloaded environment with a web-based agent inspector and trace visualizer. CLI-first.
Code-driven from the start via AI Templates and standard inference SDKs (Python, C#, JS, Java), with VS Code extensions and Foundry Local to run LLMs on-device for free.
2 · Grounding & RAG
A dedicated RAG Engine links files to LLMs, built on auto-tuned Vector Search indexes. Retrieval is its own managed service.
Grounding folds into AgentCore Memory, with retrieval strategies configured declaratively in agentcore.json. Memory and grounding are one surface.
Foundry IQ connects existing knowledge bases directly to agents — no manual chunking or vector setup. The abstraction hides the pipeline.
3 · Security, safety & governance
Agent Gateway inspects payload traffic; Semantic Governance configures granular behavior policies. Access is gated through Google Cloud IAM.
AgentCore Gateway governs tool connectivity; AgentCore Identity bridges third-party keys and OAuth so agents act with scoped credentials.
Control Plane packs enterprise-grade Content Safety — red teaming, input/output filtering — plus deep audit tracing as a first-class feature.
Agentic Coding Environments, IDEs & Tools
These are developer tools designed to write, test, debug, and run code directly inside repositories. They diverge most on two axes: how you inject persistent context, and how much autonomy you grant the sandbox.
walkthrough.mdCLAUDE.md / Auto Memory.cursorrules / Semantic Index/loop etc.)1 · Instructions & context injection
Reads CLAUDE.md from the project root at the start of every session to align with your styling guidelines. It also tracks Auto Memory — saving build commands, diagnostic paths, and tricks learned across sessions.
Relies on .cursorrules files and builds a secure codebase index for full semantic search across the repo (invoked with the @Codebase symbol).
Uses Implementation Plans (implementation_plan.md), Tasks (task.md), and Walkthroughs (walkthrough.md) stored in the app data directory to enforce explicit phases: Research → Plan → Review → Execute → Verify.
2 · Execution sandboxes & autonomy
Supports Routines — running on managed Anthropic cloud sandboxes as asynchronous webhook/cron loops — alongside local terminal tool execution.
Composer 2.5 runs tests and tracks compilations inside Shadow Workspaces. Agent Mode exposes a visual autonomy slider — autocomplete, inline edits (Cmd+K), or a fully autonomous Cloud Agent.
Operates a structured sandbox with gated shell-command authorization. Mutating state requires an explicit, user-approved handshake transaction before execution.
A note on OpenAI Codex. Codex sits in this category as a cloud-and-CLI coding agent, but it maps cleanly onto the same five primitives above — an orchestration engine, an instructions file, repeatable commands, action hooks, and a sandboxed runtime. Once you can read the columns, a new entrant rarely needs its own row; it just fills the existing ones with new names.
Data-Native & App Builders
These tools bridge the gap between heavy enterprise data lakes and interactive, user-facing applications. The shared pattern is the same in both: an agent generates a UI that reaches a governed SQL warehouse through scoped, audited credentials.
The data-to-app pipeline — an agent at one end, a governed catalog at the other
Nomenclature cheat sheetBuild inside the Agent Framework
- Register the tools. Expose secure SQL query tools as Unity Catalog Functions.
- Orchestrate. Design with a Supervisor Agent in Python, or start from a Knowledge Assistant template.
- Trace. Run and instrument execution through MLflow Tracing to log payload schemas.
- Deploy. Ship the UI directly onto Databricks Apps — serverless hosting, no separate infra.
Use the Replit × Databricks connector (Enterprise plan)
- Mint credentials. A Databricks admin creates a Service Principal — machine-to-machine client credentials.
- Register the connector. The Replit admin adds those credentials under Org Connectors and maps the SQL Warehouse hostname and HTTP path.
- Scaffold. A developer spins up an app from the Databricks App template.
- Let the agent build. Replit Agent writes the dashboard UI, reads metadata catalogs, generates secure queries, and deploys to a Replit staging URL — all from a natural-language prompt.
Skills & Extension Architecture
Skills let developers package domain-specific workflows, API specs, utility scripts, and reference instructions — turning a generalist model into a specialized tool. The format is deceptively simple: a directory with a known structure that the runtime loads in layers.
| Capability | Agent Skills (API) | Claude Code Skills | claude.ai Custom Skills |
|---|---|---|---|
| How to install | Set skill_id in the API container config |
Store directory in .claude/skills/ |
Upload a .zip package in UI settings |
| Discovery | Auto-triggered via YAML description |
Auto-triggered via YAML description |
Auto-triggered via YAML description |
| Sharing scope | Workspace-wide — shared API resource | Personal or project — Git-trackable | Individual only — no admin share |
| Network access | Strictly blocked — local sandbox only | Full access — inherits the user's machine | Variable — gated by admin settings |
| Runtime dependencies | Pre-installed packages only | Can run local pip / npm packages | Pre-installed packages only |
The reason a model can have hundreds of skills installed without drowning is progressive disclosure. Nothing heavy loads until it's actually needed — and the heaviest material never enters the context window at all.
Only the YAML name and description load at startup. This is what lets you install hundreds of skills with no meaningful token penalty — the model knows what each skill is for without reading how it works.
The body of SKILL.md is read via bash and pulled into context only if the user's prompt matches the skill's description. Procedural detail arrives exactly when it becomes relevant — and not before.
Executable scripts and heavy schemas run in the terminal; the model reads only the stdout. The raw code and reference guides never enter the context window — which is what keeps the loop fast and cost-effective even for large, complex skills.
Learn the columns, not the vocabularies.
The platforms in this guide will keep renaming things. New entrants will arrive with their own marketing terms for the same primitives. None of that should cost you a week ever again — because once you can read the rows, every "new" platform is just a fresh set of names laid over a structure you already understand: a builder, a framework, a runtime, a memory, a tool registry, a gateway, and an eval harness.
That's the real value of a Rosetta Stone. Not the translation of any single phrase — but the moment you stop translating and start reading.
The fastest engineers on a new platform aren't the ones who memorized its docs. They're the ones who recognized which familiar concept each new word was hiding.
Designing across these platforms? That's our work.
auxfirst designs agentic systems that stay coherent no matter which runtime, IDE, or skills layer they're built on — because good agent design lives above any single vendor's vocabulary.
Start a conversation →Read next & further reading
Method · Capability names are taken from each vendor's own documentation at time of writing. Platform vocabularies change frequently; treat this as a translation aid, not a specification, and check the primary docs before building.