The Signal-Activated Agent Pattern: A reference architecture for proactive government AI

In Part 1 of this series, we introduced the Signal-Activated Agent Pattern, which sends the right dimension of information to the right person based on what matters to them. This critical distinction separates proactive AI from a sophisticated alerting system.

Consider a single data event: a public health surveillance dataset updates with new respiratory illness rates across a region. That same data event is meaningful to multiple people—but in entirely different ways:

• A public health researcher needs the statistical trend—rate of change, confidence intervals, geographic clustering. Value dimension: analytical depth.
• A policymaker needs the operational implication—which jurisdictions approach intervention thresholds, what resource allocation decisions are imminent. Value dimension: decision-readiness.
• A communications director needs the public narrative—how numbers compare to last week’s messaging, what questions media will ask. Value dimension: narrative coherence.
• A field coordinator needs the logistics view—which clinics see increased volume, whether to pre-position supplies. Value dimension: ground-level preparedness.

These scenarios use the same data but with four completely different value extractions. The reference implementation achieves this through a consumer context store that maintains each person’s identity, role, and value dimensions in Amazon DynamoDB. When the event arrives, a hot-path filter AWS Lambda function evaluates it against each consumer’s watch conditions independently. Matching events escalate to an agent invoker that calls Amazon Bedrock with the full assembled context, producing a role-shaped response unique to each consumer.

This is why consumer context must exist before the system reacts. Without it, the system can’t distinguish between alerting and serving.

In Part 2 of our two-part series, we discuss the architecture of the Signal-Activated Agent Pattern and its application for proactive government AI. For Part 1, see Signal-activated generative AI: How agencies can reach more people and react faster.

Solution overview

The implemented pattern has two layers. Both share the same consumer context model and event ingestion pipeline:

• Notification layer – Delivers role-shaped insights: event → filter → contextual Amazon Bedrock invocation → multi-channel delivery. This is the “tell the official what they need to know” path.
• Action layer – Enables agents to take action when authorized: event → filter → contextual evaluation → execute capability (autonomous or human-supervised). This is the “do something about it” path.

Both layers share four foundational components:

• Event ingestion (Amazon EventBridge) – Your agency’s data sources—case management systems, sensor networks, financial platforms, citizen portals—emit events to Amazon EventBridge when data changes. EventBridge provides serverless, content-based routing at millions of events per second. Inbound email through Amazon Simple Email Service (Amazon SES) is also supported as an event source, so your agency can wire existing email-based reporting into the activation pipeline.
• Deterministic filtering (AWS Lambda hot-path filter) – A hot-path filter Lambda function performs deterministic pre-filtering against each consumer’s watch conditions. This includes threshold checks, status transitions, geographic boundaries, and time-based rules. This layer resolves over 80 percent of incoming events at sub-cent cost. The filter is user-specific: the same event might match one official’s watch conditions while being correctly suppressed for another. Events requiring contextual judgment escalate to Amazon Bedrock. A secondary digest runner Lambda function aggregates non-urgent signals into scheduled briefings.
• Contextual AI agent (Amazon Bedrock agent invoker) – When a signal escalates, the agent invoker Lambda function calls Amazon Bedrock as a stateless HTTPS API with the full consumer context assembled from DynamoDB. The agent knows if this is a researcher who needs analytical depth or a policymaker who needs decision options. The same underlying event produces a completely different response for each consumer, shaped by their identity context, operational state, and expressed value dimensions.
• Multi-channel delivery (Amazon SES and delivery router) – A delivery router dispatches the personalized response through the consumer’s preferred channel. Amazon SES handles email (both outbound notifications and inbound replies that feed back into the event pipeline). Webhook callback URLs enable delivery to Slack, Microsoft Teams, or custom portals. The channel itself is part of the consumer context.

From insight to execution using the action layer

The notification layer tells officials what they need to know. The action layer enables the agent to do something about it—under controlled conditions with explicit safety boundaries.

Each watch condition can authorize one or more capabilities—typed actions the agent can take when the watch triggers. A capability might be “send a compliance reminder email,” “create a ticket in your agency’s case system,” or “pre-stage supplies at a regional depot.” Capabilities operate in two modes:

• Autonomous – The agent acts immediately under pre-authorized conditions. It is bounded by per-capability rate limits (for example, “no more than five emails per consumer per day”), reversibility tiering, and an AWS Systems Manager backed system-wide emergency switch that halts autonomous actions instantly if needed.
• Supervised – The agent generates a proposed action and delivers an approve/reject/edit card using Slack, Teams, or a webhook callback URL. The action executes only after explicit human approval. Irreversible actions are supervised-only by system policy—not user choice.

Reversibility tiering classifies each capability into one of four levels: safe (read-only queries), reversible (actions with automated undo), effort-to-reverse (manual cleanup required), and irreversible (can’t be undone). This classification is enforced at the capability registry level. An administrator can’t configure an irreversible action for autonomous execution—the system rejects it, which is a structural constraint to maintain safeguards.

Open-protocol pluggability

Your agency has existing tools: CRMs, ticketing systems, custom RPA, legacy mainframe interfaces. The pattern integrates these through the Model Context Protocol (MCP). Adopters register the MCP-compliant server with the runtime; each tool the server exposes automatically becomes a typed capability in the system—with the same safety pipeline, reversibility classification, rate limits, and emergency switch coverage.

An MCP capability adapter translates between the runtime’s typed capability interface and the MCP server’s tool definitions. This means your agency can configure new action targets without modifying the core pattern. For example, a ServiceNow MCP server, a Salesforce MCP server, or a custom agency-built MCP server for legacy systems can become available capabilities of the action layer with no additional configuration.

Single-table DynamoDB design for consumer context

The consumer context model lives in a single DynamoDB table with three global secondary indexes (GSIs) optimized for the pattern’s access patterns:

• GSI-1 (by-source) – Indexes watch conditions by event source. When an event arrives, the hot-path filter queries this index to find consumers watching that source type. This is the critical hot-path query—it must be fast, and it is, providing single-digit-millisecond DynamoDB reads.
• GSI-2 (by-role) – Indexes consumers by role for persona fan-out. When a system-seeded watch activates (see the next section), this index identifies each consumer in the relevant role instantly, enabling broadcast of critical signals to all officials who must receive them.
• GSI-3 (by-capability) – Indexes action records by consumer and capability. Used for rate-limit enforcement on the action layer: before an autonomous action executes, the system queries this index to verify the per-capability rate limit hasn’t been exceeded.

The same table stores identity context (role, value dimensions, preferences), operational context (current priorities, active decisions), signal buffer items (accumulated events since last touch), watch conditions, and action audit records. With a single-table design, you can avoid cross-table joins, and access patterns are served by indexed queries.

System-seeded persona defaults

Some signals aren’t optional. For example, in the event of a disease outbreak trigger, a Class I product recall, or a critical infrastructure failure, each official in a given role must receive these regardless of personal preferences. The pattern supports system-seeded watches: critical-event conditions configured by administrators that trigger automatically for each consumer assigned to the relevant role. These are invisible to user-authored watch management, non-removable by individual consumers, and indexed using GSI-2 for efficient role-based fan-out.

Two paths into the same runtime

The system supports two entry points into the same AI runtime:

• Official-initiated – An official asks a question. The agent invoker responds with full consumer context—informed by their role, current priorities, and long-term context history accumulating in their signal buffer.
• System-initiated – A data event triggers the hot-path filter. The agent invoker evaluates through the lens of this consumer’s context and delivers a personalized, role-appropriate insight—or, if the watch authorizes action capabilities, proposes or executes an action.

Both paths use the same context store, Amazon Bedrock invocation pattern, and delivery router. The official experiences a coherent assistant regardless of which path triggered the interaction.

The following diagram shows how both activation paths—whether an official asks a question or a data event triggers the system—flow through the same consumer context store before the agent responds. The diagram also illustrates the dual output: notification layer (role-shaped insights) and action layer (autonomous or supervised execution), with the Systems Manager emergency switch providing immediate halt capability.

Figure 1: Both activation paths—official-initiated and system-initiated—flow through consumer context before the agent responds

Secure runtime model

A common concern with agentic systems is uncontrolled behavior—an AI process running persistently, accumulating state, potentially drifting from its intended scope. The Signal-Activated Agent Pattern addresses this structurally:

• There is no persistent AI process – Amazon Bedrock is a stateless HTTPS API. The Lambda function calls it, receives a response, and terminates. There is no large language model (LLM) agent running between events, persistent socket, or accumulated hidden state. Each invocation is independent, bounded, and observable.
• Capability binding is structural, not textual – When a watch is authored, it explicitly declares which capabilities the agent might invoke if that watch triggers. This binding is stored in DynamoDB at author-time. At activation-time, the agent invoker enforces this binding before any action executes. Even with a malicious inbound event payload, the agent can’t deviate to call a capability the watch didn’t authorize. This safety property bounds prompt injection: the model can generate whatever text it wants, but the action executor only permits capabilities that were structurally pre-authorized.
• Emergency switch is immediate – Parameter Store, a capability of AWS Systems Manager, uses a flag to serve as a global emergency switch. When flipped, autonomous action execution halts within one Lambda function cold-start cycle. There is no graceful shutdown negotiation or queued actions draining. Notifications continue unaffected; only the action layer pauses.

Watch conditions for conversational configuration

The system learns what each consumer needs through natural conversation. For example, a researcher says: “Alert me when any county shows a two-standard-deviation increase in respiratory cases.” A policymaker says: “Let me know when projected hospitalizations in my region approach 80 percent of surge capacity.” A field coordinator says: “Flag me when any clinic in District Four reports supply shortages.”

The system extracts these into structured watch conditions stored in DynamoDB (indexed by GSI-1 for the hot path). Each watch specifies the event source, the filter criteria, the notification template, and optionally the authorized capabilities for the action layer. The solution doesn’t use configuration portals or IT tickets. Officials express what they need in their own words, and the system monitors on their behalf.

Two-package architecture deployment

The reference implementation ships as two packages:

• Runtime framework – Core primitives, such as context store, capability registry, delivery router, action executor, hot-path filter logic, and digest runner. This framework is unit-testable without AWS credentials. Your agency can write and validate watch conditions, capability definitions, and persona configurations locally before deploying.
• AWS CDK construct library – The AWS Cloud Development Kit (AWS CDK) offers infrastructure as code (IaC). One top-level construct (SignalAgentStack) provisions the recommended topology: EventBridge bus, Lambda functions (hot-path filter, agent invoker, digest runner, action executor), DynamoDB table with three GSIs, Amazon SES configuration, Amazon API Gateway endpoints, and Systems Manager parameters. Lambda code is bundled at publish time—your agency runs a single AWS CDK deploy command.

This separation means your agency can adopt incrementally: start with the notification layer, validate the consumer context model, then enable the action layer when you’re ready for supervised and autonomous capabilities.

Mission impact for your agency

When your agency deploys contextual signal-activation, the impact compounds:

• Reach more people – Proactive identification of eligible constituents and at-risk populations. Your agency finds the people who need help rather than waiting for applications.
• React faster with the right context – The gap between “data changed” and “a qualified official knows and can act” reduces to minutes, and the information arrives pre-shaped for their decision-making needs.
• Each consumer gets their value dimension – The same underlying data surfaces as statistical analysis for researchers, decision briefs for policymakers, logistics summaries for coordinators, and narrative context for communicators.
• Act, not just inform – With the action layer, the system moves from “here is what you need to know” to “here is what I can do about it, with your approval”—or, for pre-authorized safe actions, handles routine responses autonomously.
• Scale without proportional headcount – The system monitors thousands of data streams simultaneously, personalized for each official. Serverless architecture means costs scale with actual events processed, not provisioned capacity.

Looking forward: The voice-activated intelligence layer

Let’s imagine taking this pattern one step further. Instead of configuring watch conditions through text, picture an official’s first interaction with the service as a voice conversation: “Tell me about your role. What are your current priorities? What keeps you up at night? What would you want to know the moment it happens?”

The official speaks naturally. As they do, the system builds a persona profile in real time: extracting value dimensions, identifying decision patterns, mapping the types of signals relevant to this specific person. That persona becomes the lens through which incoming data is processed.

In response, the voice interface activates: “Good morning. Three developments overnight are relevant to your current priorities. The first relates to the enrollment threshold you mentioned. Would you like me to walk you through the details, send a summary to your team, or explore the cross-cutting impacts on downstream programs?”

The official chooses. Each response triggers a different action—because the system understands not just what happened in the data, but what this person can do with it given their authority and current context. With the action layer in place, a message like “send a summary to my team” actions the user-directed instruction immediately.

Each component for this solution—voice interfaces (Amazon Lex, Amazon Transcribe), persona modeling (DynamoDB, Amazon Bedrock), real-time event processing (EventBridge, Lambda), and voice delivery (Amazon Connect, Amazon Polly)—is offered as managed AWS services. The pattern described in this series is the foundation; the voice-activated intelligence layer is the next step your agency can build on top of it.

The following diagram depicts the continuous refinement loop enabled by voice-activated persona building. Each cycle sharpens the system’s understanding: the official’s spoken priorities become structured watch conditions and capability authorizations, data is filtered through that persona, insights and action choices are delivered, and the system learns from which activations drove real action and which were ignored.

Figure 2: The continuous refinement loop: voice builds the persona, data is processed through it, insights are delivered with choices, and subsequent interactions sharpen the system’s understanding of what this user needs

Traditional vs. signal-activated government AI

The following table compares the features of traditional AI with signal-activated AI.

Conclusion

The reference implementation is complete: notification layer, action layer (autonomous and supervised modes), open-protocol capability adapter, system-seeded persona defaults, and single-table DynamoDB design with three GSIs. The implementation undergoes AWS validation—deploying against live Amazon Bedrock endpoints, Amazon SES delivery, and production DynamoDB tables.

AWS Public Sector teams will work with interested agencies to scope pilot deployments. Reach out to your AWS account team for engagement details.