Evaluation FAQ

The questions raised during the evaluation, answered directly, with the page or the code that holds the detail.

"Can you send me anything that goes over your tech stack? Where everything lives, what it is written in, what frameworks, third parties you are using, for example Kubernetes."

The full inventory is on Technology stack. In one paragraph: the control plane is Node.js 24 (Fastify backend, an MCP server and chat host on Express and the MCP SDK) and one React 19 SPA built with Vite and Tailwind; the engine plane is a TypeScript engine on RxJS with MongoDB and Redis, running per-project forks; generated applications run as their own containers built in-cluster with kaniko. Stores are Dolt (versioned configuration), Postgres 16 (platform state and pipeline targets, pgvector for retrieval), MongoDB 7, Redis 7 and S3. Everything runs on one AWS EKS cluster (dev and prod namespaces) behind the AWS load balancer controller with ACM and Route53, deployed by Bitbucket Pipelines to ECR, with cluster infrastructure in Terraform. Models are reached through Amazon Bedrock by default. Third parties are listed by name with versions.

"Today we are using Bedrock, AgentCore and LangChain/LangGraph."

You can keep all three, and a project built on cortex needs none of them except the models.

Bedrock: cortex agents run on Bedrock today. The production transport is the vendor's Bedrock SDK with the pod's IAM role, and the model for each consumer is a registry row; nothing in a cortex agent is specific to a vendor SDK.

AgentCore and LangGraph: cortex has its own orchestration layer, business workflows, where a step assigned to an agent actor is what a tool-calling agent node is in a graph framework, with a human gate, triggers, a version history and a runs inbox already attached (see Agentic workflows). So for new work on cortex there is nothing to orchestrate from outside. For the systems you already have, cortex is a tool and agent provider: every cortex tool is an MCP tool over Streamable HTTP and every cortex agent is an MCP tool on the orchestrator endpoint. A LangGraph graph consumes them with langchain-mcp-adapters; an AgentCore gateway registers them as an MCP target; both snippets are on Agents and MCP. In the other direction a cortex agent's tool is an endpoint, and an endpoint can call an AgentCore gateway or any MCP server of yours.

"Initially we gave the models tools explicitly but we are pivoting to exposing tools using MCP and then having agents use the MCP connectors."

That is exactly the cortex model. There is one way to add a capability (an endpoint on the project's fork) and it is immediately a typed MCP tool for agents inside the platform and for MCP clients outside it. Inside the platform an agent's .mcp.json names one server; the server resolves the agent's handle to its manifest and registers the manifest's tools. There is no per-agent tool wiring, no adapter code and no drift between what the UI calls and what the agent calls.

"Much of the time we take to build an agent or an agentic workflow is building up the support, such as APIs or handling configuration information."

The support is a property of the platform rather than a task of the project; the table on Delivery lifecycle goes item by item. APIs: an endpoint is the API, the UI data source and the tool at once, and the fleet authors it from a card. Configuration: the per-fork environment is injected into every inherited operation through one wrapper; secrets are per project and rotatable. Model routing: a registry table. Deployment: containers built in-cluster and published at a hostname. Documentation: generated from the service definitions.

"Or establishing guardrails to make sure it never gives an incorrect answer."

Two layers, both described on Guardrails and correctness.

Capability guardrails bound what an agent can touch: only its manifest's tools, only its own project, no shell or file access, fail-closed access control, attributed writes. These hold by construction.

Correctness guardrails bound what an agent can say: scope, grounding: tools (an answer without a successful tool call behind it is refused), verify (a second, tool-less model pass checks every claim in the draft against the tool evidence and the scope), max_tool_calls, a refusal text and on_fail: refuse | annotate. They are five fields on the agent's page, enforced by the platform after every answer and before the person sees anything. Every guarded answer is recorded in a ledger with its verdict and reason. The agent test kind turns expected behaviour, including the refusals, into tests linked to requirements that run on a schedule and alert on Slack.

Honest framing: no platform can make a probabilistic model infallible. What cortex does is ensure that an unsupported claim does not reach a person unmarked, that every answer is traceable to the tool evidence behind it, and that regressions are caught by tests rather than by users.

"Does the tech stack of cortex restrict the tech stack of the generated application?"

No. A generated application is an app service: an arbitrary Dockerfile plus source tree stored verbatim on the project's fork, built in-cluster and run as its own Deployment. The engine's own words: "a whole application with its own HTTP surface, a .NET 8 web app, a Go binary, an nginx, whose source tree and Dockerfile come verbatim from the project". .NET 8 with Duende IdentityServer and SQL Server, Node 20 and Python 3.11 are in production or proven by tests. Details on Independent applications.

"Can the generated application be fully independent from cortex and supportable without cortex at all?"

Yes, and that is the default. The customer archive contains the application's own source and containers, a compose file, optional Kubernetes and Azure manifests, optional CI pipelines, a generated runbook and README, per-archive secrets and the tests. It contains no cortex runtime unless a companion (chat, workflows, guides, models, pipeline, governance, docs) was explicitly switched on for distribution; all are off by default. There is no license check, no callback and no cortex dependency in the application code. A customer who leaves keeps ordinary software; a customer who stays keeps the requirements chain, the fleet and the watchdog.

"Where does an agent's process run and what is it?"

In the assistant pod, one child process per delegated task or pinned turn: the headless agent runtime, a Node bundle that drives the vendor SDK over the environment's transport and speaks MCP to exactly one server, the platform's loopback agent route. It has no built-in tools and is removed at the end of the turn. Chat sessions and fleet workers are described alongside it on Agents and MCP, with the diagrams.

"What would a pilot look like?"

Pick one application with a real requirements document and a real data source. Upload the document, approve a preview variant, let the fleet build the application as an app service in your chosen runtime, and add one agent over it with tools-only grounding and verification on. Connect your LangGraph or AgentCore stack to the project's MCP endpoint with an access token. Watch the Status page and the guardrail ledger for a week. Then export the customer archive and run it outside cortex. Each of those steps is a page on this site and a screen in the product.