Positioning
The question that ended well in the call: how is cortex different from a code generator (Cursor, Claude Code) and from an agent framework (LangGraph, Google's ADK)? Allvue answered it themselves: consistency. Developers use the same environment, tools are created once and reused across workflows, agents orchestrate those workflows and tools, and the whole thing is tested, versioned and governed the same way. This page makes that answer precise.
What each thing is
| Generates code | Runs agents | Governs the lifecycle | |
|---|---|---|---|
| Cursor, Claude Code | Yes, in an editor or a terminal | No | No |
| LangGraph, ADK | No | Yes, as a library a team embeds | No |
| Cortex | Through the fleet, which drives a coding agent as one of its workers | Yes, as data (a manifest), with tools pinned server-side and safeguards enforced after every answer | Yes: requirements, data, tools, workflows, agents, application, tests, security, versioning, deployment, audit, in one place |
Everyone has good code generation now. That is not the product. The product is that a requirement, the endpoint that satisfies it, the test that proves it, the agent that uses it, the workflow that runs it, the deployment that ships it and the audit trail that records all of it are one connected, versioned structure.
What that looks like in cortex, concretely
| Lifecycle stage | What it is in cortex | Why it matters to a platform team |
|---|---|---|
| Requirements | Uploaded documents become rows with verbatim citations; every passage is covered; a later document is a delta review, never a regeneration | The specification is traceable to its source and to the code, and it does not drift |
| Data | Sources, elements, rules, targets as versioned configuration; a pipeline that runs and a structure check that runs in two seconds without moving data | The data layer is governed the same way for every project |
| Tools and services | An endpoint is the application's data operation, the test's target and the agent's tool at once; app services are ordinary containers | One thing to review, not three |
| Workflows | Drawn as data, run by the engine, with human gates and agent actors | Process logic is not buried in application code |
| Agents | A manifest, no code; safeguards enforced after every answer and recorded in a ledger; MCP for anything external | An agent can be reviewed, tested and audited like configuration |
| Application | An app service from a scaffold, or any runtime with a Dockerfile | The customer's runtime choice is respected |
| Testing | Requirement-linked tests of five kinds, one runner everywhere, a watchdog every fifteen minutes, a gate on promotion | Health is a property of the requirement, not a separate project |
| Security | One access rule, versioned data policies, per-project secrets, attributed commits | Governance is inherited, not reimplemented per team |
| Versioning | Every configuration write a commit; every endpoint save a version; every export a commit; a branch per change with its own fork | Rollback and review are native |
| Deployment | Export as ordinary source with compose, Kubernetes, Container Apps, CI and a runbook; nothing depends on cortex at run time | The customer keeps normal software |
| Audit | The commit history, the timeline, the ledger, the evidence on every task | The question "what is running and why" has one answer |
The sentence we will use
Cursor and Claude Code generate code. LangGraph and ADK run agents. Cortex governs the creation and operation of the software those produce: from the requirement to the deployed, tested, audited service, consistently for every team.
Where the others fit
A team that already uses LangGraph or ADK connects it to cortex over MCP, in either direction: the project's tools and agents are MCP servers, and a cortex agent's tool can be an endpoint that calls an external MCP server. A team that uses Cursor keeps using it; the fleet drives a coding agent, and a developer who edits by hand does so in the same tree. See Developer code and generated code.