The biggest companies in tech are converging on the same conclusion: AI agents without organizational knowledge are a liability. Here's what they're each building, and what the pattern reveals.
Something shifted in the last six months.
If you've been watching how the major platforms are investing in agentic AI, the pattern is hard to miss. Amazon, LinkedIn, Google, Microsoft, Salesforce — they're all building the same thing, from different directions, using different languages. But underneath the product names and feature announcements, the thesis is identical:
AI agents that don't know how your organization works will eventually do something your organization wouldn't approve.
The race isn't to build and utilize smarter models in many enterprise workflows. It's to build the knowledge infrastructure that keeps agents aligned with the organizations they serve. And the approaches these companies are taking reveal a lot about where the industry is headed — and what's still missing.
LinkedIn: "Agents Fundamentally Lack Organizational Context"
LinkedIn may have articulated the problem most clearly.
When their engineering teams deployed AI coding agents — tools like GitHub Copilot that are remarkably capable at generic programming tasks — they hit a wall. The agents could write code. They couldn't write LinkedIn's code. They didn't know the company's thousands of microservices, its internal frameworks, its data infrastructure, its specialized systems. The agents were fluent in programming but illiterate in the organization.
LinkedIn's solution was CAPT — Contextual Agent Playbooks and Tools — a framework built on the Model Context Protocol (MCP) that gives AI agents access to internal tools and executable playbooks encoding institutional workflows. Not documents to search through. Executable, structured knowledge that agents can act on.
The results, by January 2026, were concrete: over 1,000 engineers using the system regularly, 70% reduction in issue triage time, 3x faster data analysis workflows, and automated debugging that cuts time spent by more than half across multiple engineering domains.
But the philosophy matters more than the metrics. LinkedIn's position is that "investment in context and tooling may yield higher returns than investment in model sophistication." Read that again. One of the world's largest engineering organizations is saying: the bottleneck isn't the model. It's what the model knows about your organization.
Their approach to playbooks is instructive, too. Small, focused playbooks that each do one thing well, designed to combine into sophisticated workflows when agents chain them together. A building-blocks approach to institutional knowledge: not monolithic documents but composable organizational intelligence.
By building on MCP rather than proprietary integrations, LinkedIn gained compatibility across multiple agents and can adopt improvements from the broader ecosystem without vendor lock-in. The infrastructure is open, but the organizational knowledge it delivers is specific, structured, and governed.
Amazon: "Making Sure Agents Can't Give Away the Store"
Amazon's approach tells a different part of the same story.
At re:Invent 2025, AWS announced AgentCore Policy, a new layer within Amazon Bedrock AgentCore that defines clear boundaries for what agents are allowed to do. The New Stack's headline captured it perfectly: "AWS' New Policy Layer in Bedrock AgentCore Makes Sure AI Agents Can't Give Away the Store."
The technical architecture is revealing. Policies are defined using Cedar, an open-source language for fine-grained permissions, or in plain English that gets translated into Cedar automatically. But here's the key design decision: policy enforcement happens outside the LLM reasoning loop. Every agent action through the AgentCore Gateway is intercepted and evaluated against defined policies before it reaches a tool. The enforcement is deterministic, not probabilistic. It doesn't depend on the model interpreting a guideline correctly. The policy layer says yes or no before the action executes.
You can write rules like "agents can only access customer data during business hours" without writing custom authorization logic. Natural language goes in, validated Cedar policies come out, and automated reasoning checks for policies that are overly permissive, overly restrictive, or contain conditions that can never be satisfied.
This matters because it separates knowledge from enforcement. Bedrock Knowledge Bases give agents information. AgentCore Policy tells agents what they're allowed to do with it. Amazon is building both layers, and explicitly positioning them as distinct architectural concerns that work together.
AgentCore Evaluations adds a third dimension: 13 built-in quality evaluators that monitor agents in production, plus custom evaluators for business-specific requirements. Knowledge, policy, evaluation. Three layers, one system.
But Amazon didn't stop at infrastructure. They open-sourced a fourth piece that may matter most for day-to-day enterprise operations: Agent SOPs — Standard Operating Procedures written in markdown that guide AI agents through complex, multi-step tasks using natural language.
The origin story is revealing. When Amazon's internal teams deployed agents using the Strands SDK, they hit the same wall LinkedIn described, but from the opposite direction. LinkedIn's agents lacked organizational context. Amazon's agents had context but produced wildly inconsistent behavior. The same agent that performed flawlessly during development made different decisions about tool usage, task prioritization, and output formatting when handling real-world production scenarios. Without structured guidance, capable agents became unreliable agents.
Agent SOPs were the answer. They use RFC 2119 keywords — "MUST," "SHOULD," "MAY" — embedded in natural language markdown to create a middle ground between rigid code and freeform prompting. Teams can author new SOPs in minutes. Coding agents can even generate new workflows from natural language descriptions, making the creation process accessible regardless of prompt engineering expertise.
The internal adoption was massive. Amazon teams now use thousands of SOPs across a range of use cases, from code reviews and documentation generation to incident response and system monitoring. The consistent format made it easy to share successful approaches between teams while adapting them for different contexts.
Two production case studies demonstrate the approach in action. The OASIS project uses AI agents to automate IT incident management. Agents autonomously detect anomalies, correlate events across services, and provide data-driven resolution with minimal human intervention. A separate multi-agent incident response system pairs a monitoring agent built on Strands with an operations orchestrator that triages incidents, coordinates ChatOps, and generates tickets — all communicating through the Agent-to-Agent (A2A) protocol.
SOPs also include built-in progress tracking: agents document their work as they go, making it easy to understand what happened and resume if something breaks. For enterprise teams, this transparency was crucial for building developer trust in AI automation and creating the audit trails that compliance requires.
Perhaps most significantly, Amazon designed Agent SOPs to be cross-platform by default. They work in Strands Agents, Kiro, Cursor, Claude Skills, any MCP-compatible tool, and directly in LLMs like Claude and GPT-4. The repository is open source on GitHub. This is Amazon explicitly saying: the value of structured operational knowledge shouldn't be locked to our platform.
Amazon's full stack is now four layers deep: Knowledge Bases for information, AgentCore Policy for enforcement, Evaluations for monitoring, and Agent SOPs for operational workflows. Each layer solves a different failure mode: agents that don't know enough, agents that do too much, agents that degrade silently, and agents that execute inconsistently.
Part 2 covers Google, Microsoft, Salesforce — and the cross-platform gap none of them have solved.