AgentEchelon: A governed, multi-party agentic AI platform that puts humans and agents on the same control plane

Audience: Business & Technical Purpose: Introduction to AgentEchelon

Businesses continue to insert AI into an increasing number of workflows: an assistant triaging IT tickets, internal AI tools to help employees with documentation, coding agents in the deployment flow. Solutions adopted are often not consistent across the company, and typically bolted on with additional services to control what agents can do, and the approvals never keep up with the ideas. Human interaction sits across another seam, or many depending on how many applications they use to engage with AI, governed by a different system entirely. So agents are controlled in one place, people in another, and the two are stitched together for every new use case. The rules around interaction with humans, data access, history and context for the interactions, and the tools to measure effectiveness are not unified.

With AgentEchelon I am exploring taking a different path: security from the infrastructure up. It puts humans, assistants, agents, and the conversations that connect them all on one control plane, configured with AWS Identity and Access Management (IAM). With AgentEchelon, your internal employees are assigned an Amazon Resource Name (ARN), as are your authenticated customers, unauthenticated guests, the assistants they interact with, and the conversations that connect them. The conversation itself is a first-class governed resource, not just a connection between actors. The users and assistants are assigned policies that restrict their access down to only what they need. Access is an IAM decision keyed on an immutable classification tag: fail-closed, evaluated before any request runs, and provable with a deny test rather than a code review. Classifications are your labels (internal, confidential, restricted, whatever your data taxonomy already says), and each is served by a capability profile that fixes which model answers, at what depth, with what reach. The result for security reviews is that each new use case arrives as a configuration change to review, not a new system to vet entirely. Because enforcement reuses core AWS primitives, cost tracking and management ride the same tags and tools.

{
  "Sid": "AllowOwnAndLowerClassificationChannelActions",
  "Effect": "Allow",
  "Action": [
    "chime:SendChannelMessage",
    "chime:GetChannelMessage",
    "chime:ListChannelMessages",
    "chime:UpdateChannelReadMarker",
    "..."
  ],
  "Resource": "arn:aws:chime:*:*:app-instance/*/channel/*",
  "Condition": {
    "StringEquals": {
      "aws:ResourceTag/classification": ["internal", "confidential"]
    }
  }
}

Above is one statement from a generated role, using the Amazon Chime SDK's concept of channels to control access to AgentEchelon conversations. This principal, a user cleared for 'confidential,' cannot interact with a 'restricted' conversation. The condition is evaluated on every send and read, and this access is further gated by membership. If you deploy the project, the E2E suite asserts the 'AccessDenied'. An assistant's role adds only its profile's model and context grants. The cleared list is generated from the same config the runtime uses for retrieval scope, so the IAM boundary and the data boundary cannot drift apart. The same identity extends past the conversation: an actor's role carries its grants to models, context, and tools too, so chat access and resource access are one policy evaluated by one engine. The diagram below shows the full reach.

The authority plane, not the request plane. Every actor (human or assistant) is a principal above one enforcement layer; the conversation is itself the governed resource. The record captures everything, including what was refused. (Conversation access is enforced in IAM; derived-context scoping is enforced as a fail-closed metadata filter in the data plane: two mechanisms, one policy.)

On top of this core concept, I have built a platform designed for flexibility, control, and observability, complete with a sample chat app, admin console, and e2e tests you can run to populate it with data.

Where it fits

The category forming in 2026 is the agent control plane or agent gateway: the governed layer between agents and the models, tools, data, and people they reach. AgentEchelon fits it with two differences: (1) it is broader: the same governance covers the multi-party conversation and connects to surfaces people arrive through, not only an agent's tool calls; and (2) its enforcement is AWS's own (IAM over tagged resources) rather than a policy service you add separately.

How it is built: four layers

Four layers, each running on the one below. Interface is the clients people use; Communication is the connectivity that wires each client to the engine (WebSocket + REST live, WebRTC roadmap). Interaction is the engine, AgentEchelon's own code over the AWS services it composes, where access is enforced in IAM. Foundations is how the platform is deployed and managed.

Many agentic systems are a model, tools, memory, and an orchestration loop. AgentEchelon ships each of these and lets you customize or swap them out as needed, then wraps them in the enterprise layers along with governed multi-party conversation. It is organized as four layers that each run on the one below:

• Interface. The client surfaces people use: This can be an end-user app, like the chat app this project ships with to demonstrate functionality, but this can also be a custom mobile app, a widget (like the one you see on this website), a phone call, or email.
• Communication. The connectivity that wires each interface to the engine: the web (and mobile) client sends and receives over WebSocket and REST APIs for messaging today, but the seams are there to add additional channels. The pattern is proven and demonstrable on this very site: the communication widget here already handles WebRTC, inbound/outbound email, and phone on an earlier version of this architecture, so bringing those channels to AgentEchelon is a small build, not a re-architecture.
• Interaction. The engine, custom-built: AgentEchelon's own code composed over several AWS services at different levels: Amazon Chime SDK Messaging for conversations, identity, roles, retention, and channel flows; Amazon Bedrock for inference (Amazon Lex as today's invocation path). Around those services sit the assistants, memory, routing, configuration, auditing, plus the IAM policies and classification tags that turn those services into a governed multi-party runtime. Its composition root is the conversation type; five pillars (identity and access, assistant configuration, conversation configuration, connectors, auditing) compose every experience. This is where "who may act, as whom, at what capability" is expressed as IAM policy by that code and then enforced by AWS IAM itself, not by application logic that has to remember to check.
• Foundations. How the platform is deployed and operated, not what it enforces: the AWS CloudFormation stacks (CDK) that provision every resource, resource tagging for cost allocation, and the monitoring and observability that keep it running. The tags that attribute cost are the same ones the interaction layer's IAM decisions read, so cost and governance ride one mechanism.

Inference, moderation, message delivery, and retention run on AWS-managed services, so those are AWS's to operate, not yours to build. Where a deployment already owns a system, the platform allows you to plug in what you already use rather than require a replacement for it: your identity provider (Amazon Cognito by default, or your SSO/SAML/OIDC), a user-profile store (the built-in one is a reference stand-in), and connectors for outside systems of record can be built as needed.

AgentEchelon ships its chat and admin experiences as web interfaces you can swap for your own, and what actually stands up in your account is a small set of deployable components detailed in What ships today, below.

What ships today

AgentEchelon ships with a chat interface and admin interface, sitting on top of separately deployable backends. Both require the primary core, which needs to be deployed first. The admin backend sits on top of the core backend, and serves the admin dashboard.

The deployable components and the order they stand up: the primary core first; then the chat interface and the admin backend on it; then the admin interface on the admin backend. The chat interface reaches the platform in one hop, the admin interface in two.

The use cases provided today are live and governed: per-profile assistants on a self-hosted tool loop, mention routing, conversation sharing, proactive briefings, A/B experiments, drift detection, the admin console, and analytics. The sample deployment ships three classifications named basic/standard/premium, a tiered-chat example, not the platform's opinion; name them after your own taxonomy. The customer-facing use cases, federated identity providers, and additional channels are designed for and seamed. Adding them should be a small build on top of what the project ships, not a re-architecture.

Screenshots

The screenshots below use a seeded demo company (Stratum Technologies) included with the project and populated by the verification tests.

Chat App

The Chat Interface

Admin Dashboard

Admin Dashboard Overview

Try it

Read more or deploy it into your AWS account, create an admin, and run the verification test to explore the full functionality.

https://github.com/RyanSMcHarg/AgentEchelon