AWS just shipped Context and Continuum — two services that tackle the same agent problem from opposite ends

AWS unveiled two services at its New York summit this week. Context builds a knowledge graph from corporate data so agents understand what the business actually does. Continuum automatically detects, prioritizes, and fixes code vulnerabilities in agent-generated output. Different surfaces, same diagnosis: agents ship code fast but get things wrong too often.

Context is the business-knowledge layer. It ingests documentation, schemas, internal wikis, and prior work, then surfaces that context when an agent needs to make a decision. An agent writing a billing script doesn't just see the database schema — it sees the three-year history of schema migrations, the deprecated columns still in use, and the note explaining why a particular foreign key exists. The knowledge graph is versioned and queryable. AWS is positioning it as the piece that keeps agents from reinventing broken patterns or hallucinating business rules.

Continuum is the security layer. It runs static analysis on agent-generated code before it touches production, flags vulnerabilities by severity, and can auto-patch the high-risk stuff without waiting for a human review cycle. The pitch: you already have agents writing infrastructure code in Bedrock or SageMaker; Continuum makes sure that code doesn't introduce SQL injection, credential leaks, or privilege escalation before it ships.

Both services assume the same thing — that the bottleneck in agentic workflows is no longer speed. Agents already write code faster than humans review it. The new bottleneck is correctness. An agent that generates a working API endpoint in 90 seconds is worthless if that endpoint exposes customer PII or misinterprets a business rule and bills the wrong account.

Context tries to solve the knowledge problem. Most enterprises have documentation scattered across Confluence, Notion, Slack, GitHub wikis, and ten-year-old Word files on a shared drive. Nobody reads all of it. Agents definitely don't. Context is AWS's attempt to unify that corpus into a single graph that agents can query in real time. The service builds relationships between entities — this table relates to this service, this API deprecation affects these three repos, this compliance rule applies to these endpoints. When an agent asks "how do we handle refunds in the EU?", Context returns the actual policy doc, the code that implements it, and the changelog showing when it last changed.

Continuum assumes agents will keep shipping insecure code and tries to catch it before deployment. The service integrates with CI/CD pipelines, scans every commit for known vulnerability patterns, and assigns a risk score. High-severity issues get auto-patched if the fix is deterministic (parameterized queries instead of string concatenation, scoped IAM roles instead of wildcards). Everything else gets flagged for human review with a diff and an explanation.

The interesting part is that AWS is treating these as complementary, not alternatives. You need both. Context keeps agents from writing code that's technically correct but business-wrong (a refund handler that works but ignores the EU's 14-day return window). Continuum keeps agents from writing code that's business-correct but security-wrong (a refund handler that works and follows policy but also leaks credit card numbers in logs).

We've seen this problem in client work. Agents generate plausible-looking code that fails in production because they don't know the edge cases. A voice agent that books limo rides doesn't know that certain zip codes require a different dispatcher, or that rides booked after 10 PM on weekends go through a different pricing table. The agent hallucinates a dispatcher assignment or applies weekday pricing at midnight on Saturday. The code runs; the business logic is wrong.

Context won't fix that entirely — knowledge graphs are only as good as the data you feed them — but it's a better answer than expecting agents to infer business rules from API schemas. Continuum won't catch every vulnerability, but it's a faster answer than waiting for humans to review every agent-generated PR.

The real question is whether enterprises will actually populate Context with accurate, up-to-date knowledge, or whether it becomes another stale documentation graveyard. And whether Continuum's auto-patching is conservative enough to avoid breaking working code in the name of security. Both services ship with the assumption that you're already running agents in production and need guard rails, not permission. That's the right assumption in June 2026.

AWS isn't the first to notice the context problem — Anthropic has been talking about business-aware retrieval for months, and OpenAI's enterprise tier includes document grounding — but Context is the first service that treats the knowledge graph as a first-class product with versioning and API access. Continuum is less novel (GitHub has Copilot Autofix, Snyk has similar tooling), but the integration with Bedrock and the auto-patch workflow are new.

If you're running agents on AWS infrastructure, both services are worth testing. Context makes sense for any workflow where agents interact with internal APIs or modify business logic. Continuum makes sense anywhere agents touch production code. The combined pricing isn't public yet, but AWS is positioning both as add-ons to existing Bedrock usage, not standalone products.

The broader point: the agent tooling market is converging on the same set of problems. Speed was 2024's focus. Correctness is 2026's. Every vendor is now shipping some version of business-context retrieval and some version of code-security scanning. AWS's versions are tightly integrated with their existing stack, which matters if you're already on Bedrock or SageMaker. If you're not, the abstractions are interesting but the lock-in risk is real.