DEV Community: Sarath Kumar Kallayil Sreedharan

Building an AI-Assisted Message Router with SQS, Lambda, and Amazon Bedrock

Sarath Kumar Kallayil Sreedharan — Thu, 27 Aug 2026 15:51:46 +0000

This is Part 3 of the AI-Assisted Message Queue Patterns series. Part 1 introduced the architecture. Part 2 covered guardrails, confidence gating, deterministic fallback, and failure handling. Now let's connect those ideas to the reference implementation.

Repository: github.com/kallayilsreedharansk/ai-message-queue-patterns

What we're building

The goal is not to replace Amazon SQS with an AI model. The goal is to insert a bounded decision layer into an ordinary message-processing pipeline.

Producer
   ↓
Ingest Queue
   ↓
Classifier / Router
   ↓
Priority Scorer
   ↓
┌───────────────┬───────────────┐
↓                               ↓
High Priority                Standard
↓                               ↓
└───────────────┬───────────────┘
                ↓
             Process
                ↓
             Failure?
             /      \
           No        Yes
           ↓          ↓
        Complete   Retry Queue
                      ↓
               Adaptive Retry
                   /       \
                Retry      DLQ

Amazon Bedrock can assist at three decision points — routing, priority, and retry — but every model-assisted decision remains bounded by application policy.

The AWS building blocks

The reference architecture uses:

Amazon SQS for durable message buffering and processing paths
AWS Lambda for event-driven consumers and decision handlers
Amazon Bedrock for contextual recommendations
AWS SAM for infrastructure definition and deployment
Dead-letter queues for terminal failure handling

A simplified resource view:

                 Amazon Bedrock
                    ▲   ▲   ▲
                    │   │   │
Ingest SQS ──► Router ─► Priority Scorer
                           │
                 ┌─────────┴─────────┐
                 ▼                   ▼
          High-Priority SQS      Standard SQS
                 │                   │
                 └─────────┬─────────┘
                           ▼
                       Processing
                           │
                        Failure
                           ▼
                       Retry SQS
                           │
                           ▼
                    Retry Handler
                       /       \
                    Retry      DLQ

The important point is that Bedrock is invoked by the application. Bedrock does not poll SQS. For Lambda consumers, the SQS event source mapping handles polling and invokes the Lambda function.

Step 1: Ingest the message

A producer sends a normal application event to the ingest queue:

{
  "event_id": "evt-4821",
  "type": "service_interruption",
  "customer_tier": "critical",
  "region": "us-west-2",
  "payload": {
    "service": "notification-api",
    "severity": "high"
  }
}

The producer does not need to know which downstream queue will eventually process the message. That decision belongs downstream. This separation is useful because producers remain focused on publishing events rather than encoding increasingly complex routing policy.

Step 2: Build decision context

The router receives the event and constructs the context used for the decision, combining message attributes with operational signals:

{
  "message": {
    "type": "service_interruption",
    "customer_tier": "critical",
    "severity": "high"
  },
  "system": {
    "processor_a_health": "degraded",
    "processor_b_health": "healthy",
    "queue_backlog": 4200
  },
  "attempt": 1
}

This is where architecture matters. Don't send every available metric to the model just because you can — select context that can legitimately affect the decision. Useful signals might include message category, workload/SLA class, message age, retry history, queue depth, consumer health, downstream latency, congestion, and approved processing locations.

Policy constraints such as security or residency restrictions should preferably filter invalid destinations before model scoring.

Step 3: Invoke Bedrock

The Lambda function can invoke a supported model through Amazon Bedrock and request a constrained structured response:

def get_ai_recommendation(context):
    prompt = build_prompt(context)
    response = invoke_bedrock(prompt)
    return parse_response(response)

The prompt should define the action space explicitly. For routing:

You are assisting a message-routing application.

Allowed routes:
- PROCESSOR_A
- PROCESSOR_B

Return JSON only:
{
  "route": "...",
  "confidence": 0.0,
  "reason": "..."
}

The application is not asking the model to invent infrastructure. It is asking the model to recommend among known choices.

Step 4: Validate before routing

Assume Bedrock returns:

{
  "route": "PROCESSOR_B",
  "confidence": 0.92,
  "reason": "Processor A is degraded and Processor B is an approved healthy destination."
}

The next step is not send_message(decision["route"], message).

First validate:

ALLOWED_ROUTES = {"PROCESSOR_A", "PROCESSOR_B"}
MIN_CONFIDENCE = 0.7

def select_route(message, decision):
    if decision.get("route") not in ALLOWED_ROUTES:
        return deterministic_route(message)

    if decision.get("confidence", 0) < MIN_CONFIDENCE:
        return deterministic_route(message)

    return decision["route"]

Then execute the approved decision:

Bedrock → Recommendation → Validation → Policy → SQS destination

That boundary is the implementation of:

AI recommends. Policy decides. The messaging platform executes.

Step 5: Deterministic mode

The reference pattern supports running without Bedrock:

USE_BEDROCK=false

def decide(context):
    if not USE_BEDROCK:
        return deterministic_decision(context)

    try:
        decision = get_ai_recommendation(context)
        return validate_and_apply_policy(decision, context)
    except Exception:
        return deterministic_decision(context)

This gives us two useful operating modes:

AI-assisted mode:    Message → Context → Bedrock → Policy → Action
Deterministic mode:  Message → Rules → Action

Both ultimately use the same messaging infrastructure.

Step 6: Score priority

After routing/classification, the next component can evaluate urgency. Suppose the message context is:

{
  "type": "service_interruption",
  "severity": "high",
  "customer_tier": "critical",
  "message_age_seconds": 48,
  "queue_backlog": 4200
}

The model might recommend:

{
  "priority": "HIGH",
  "confidence": 0.94,
  "reason": "Critical workload and elevated service impact."
}

Policy validates the category:

ALLOWED_PRIORITIES = {"HIGH", "STANDARD"}

def select_priority(message, decision):
    if decision.get("priority") not in ALLOWED_PRIORITIES:
        return deterministic_priority(message)

    if decision.get("confidence", 0) < MIN_CONFIDENCE:
        return deterministic_priority(message)

    return decision["priority"]

Then HIGH routes to the High-Priority Queue and STANDARD routes to the Standard Queue. The queue selection represents the priority path — SQS visibility timeout is a separate processing/reliability setting and should not be confused with priority itself.

Step 7: Process the message

At this point the processing consumer works much like any other queue consumer:

Priority Queue → Consumer → Business Operation → Success / Failure

The AI layer does not need to participate in ordinary successful processing unless the workload has a reason for it. That's an important cost and latency optimization: don't invoke a model where deterministic processing already has enough information.

Step 8: Classify failure before retrying

Traditional retry behavior may look like:

Failure → Wait → Retry → Wait longer → Retry again

The adaptive retry component adds failure context:

{
  "error_type": "downstream_timeout",
  "attempt": 2,
  "downstream_health": "degraded",
  "message_priority": "HIGH"
}

A recommendation might be:

{
  "retry": true,
  "retry_delay_seconds": 180,
  "confidence": 0.88,
  "reason": "Failure appears transient but downstream service remains degraded."
}

Or:

{
  "retry": false,
  "confidence": 0.96,
  "reason": "Failure appears permanent."
}

Policy then applies hard boundaries:

MAX_ATTEMPTS = 5
MIN_RETRY_DELAY = 30
MAX_RETRY_DELAY = 900

def retry_policy(message, decision, attempt):
    if attempt >= MAX_ATTEMPTS:
        return {"action": "DLQ"}

    if decision.get("confidence", 0) < MIN_CONFIDENCE:
        return deterministic_retry(message, attempt)

    if not decision.get("retry", False):
        return {"action": "DLQ"}

    delay = decision.get("retry_delay_seconds", MIN_RETRY_DELAY)
    delay = max(MIN_RETRY_DELAY, min(delay, MAX_RETRY_DELAY))

    return {
        "action": "RETRY",
        "delay": delay
    }

The model can recommend. It cannot create attempt number six when policy allows only five.

Step 9: Handle failure classes deliberately

A useful baseline:

              Processing Failure
                     ↓
               Failure Class
          ┌──────────┼──────────┐
          ↓          ↓          ↓
      Transient   Permanent   Ambiguous
          ↓          ↓          ↓
       Retry        DLQ      Bounded Retry
                                ↓
                            Re-evaluate

Class	Examples
Transient	Timeout, temporary throttling, short-lived dependency failure
Permanent	Invalid payload, unsupported operation, non-recoverable validation failure
Ambiguous	Unknown dependency error, incomplete response, unclassified application failure

AI assistance is most interesting in the ambiguous middle. Deterministic rules should continue handling obvious cases whenever possible.

Step 10: Preserve idempotency

SQS consumers must be designed for possible duplicate delivery — that remains true whether the route was selected by a lookup table or an AI-assisted decision. Use a stable producer event identifier and derive the idempotency key from it:

if already_processed(event_id):
    return

process(message)
record_success(event_id)

Do not generate a new logical identity merely because a message moved between processing paths.

Step 11: Add observability around decisions

Normal messaging metrics are not enough once an AI-assisted decision layer exists. Record both operational outcomes and decision outcomes:

{
  "event_id": "evt-4821",
  "decision_type": "routing",
  "decision_source": "bedrock",
  "selected_route": "PROCESSOR_B",
  "confidence": 0.92,
  "fallback_used": false,
  "policy_version": "v3",
  "decision_latency_ms": 214
}

Useful metrics: model invocation count, model invocation failures, decision latency, fallback rate, low-confidence rate, policy rejection rate, messages per destination, retry count, DLQ count, and end-to-end processing success.

The most useful operational question is: did AI-assisted decisions improve the outcome compared with the deterministic baseline? Without that comparison, adding a model is just adding complexity.

Step 12: Deploy incrementally

Because the architecture is built with separate components, adoption can happen one decision at a time.

Phase 1 — deterministic baseline. USE_BEDROCK=false. Validate the entire messaging path.

Phase 2 — shadow mode. Invoke the model but do not let the recommendation change production behavior.

Message ─┬──► Deterministic Decision ──► Production
         └──► AI Recommendation ───────► Logs / Evaluation

Compare results.

Phase 3 — gated AI assistance. Enable recommendations only for a limited category of messages. Keep confidence thresholds and fallback active.

Phase 4 — expand based on evidence. Only expand to additional routing, priority, or retry scenarios if measured results justify it.

This is much safer than enabling AI across the entire pipeline at once.

AWS SAM as the deployment boundary

The reference project uses AWS SAM so the infrastructure and functions can be versioned together. A simplified template shape looks conceptually like:

Resources:
  IngestQueue:
    Type: AWS::SQS::Queue

  RouterFunction:
    Type: AWS::Serverless::Function

  HighPriorityQueue:
    Type: AWS::SQS::Queue

  StandardQueue:
    Type: AWS::SQS::Queue

  RetryQueue:
    Type: AWS::SQS::Queue

  ProcessingDLQ:
    Type: AWS::SQS::Queue

The actual repository should remain the source of truth for resource names and deployment configuration: ai-message-queue-patterns

Testing the pipeline

A useful test matrix includes both model-assisted and deterministic behavior.

Routing tests

Case	Expected result
Known message	Expected route
Unknown message	Valid recommendation or fallback
Forbidden destination	Policy rejection
Low confidence	Deterministic route
Bedrock failure	Deterministic route

Priority tests

Case	Expected result
Critical context	High-priority recommendation
Routine context	Standard recommendation
Invalid priority	Fallback
Low confidence	Fallback

Retry tests

Case	Expected result
Transient failure	Bounded retry
Permanent failure	Terminal handling
Attempt limit reached	DLQ
Excessive model delay	Clamp/reject
Model unavailable	Deterministic retry policy

Reliability tests

Case	Expected result
Duplicate delivery	Idempotent outcome
Malformed model JSON	Fallback
Timeout	Fallback
DLQ redrive	Expected behavior

The interesting test is not whether Bedrock returns an answer. It's whether the whole system remains predictable when Bedrock does not.

What this pattern is — and isn't

This pattern is useful when message-processing decisions genuinely depend on contextual signals that are difficult to express cleanly with static rules alone. It is not an argument for sending every SQS message through an LLM.

A good implementation may look like:

Simple decision       → Deterministic rule
Context-heavy decision → AI recommendation → Deterministic policy

The goal is not to maximize model usage. The goal is to improve selected decisions without surrendering control of the system.

Putting the series together

Across these three articles, the architecture evolved from:

SQS → Fixed Logic → Action

to:

SQS → Consumer → Context → AI Recommendation → Policy → Messaging Action

Part 1 asked where AI might help. Part 2 asked how to constrain it. Part 3 showed how the pieces fit together in an implementation.

The pattern I keep coming back to is intentionally simple:

AI recommends. Policy decides. The messaging platform executes.

That separation lets us experiment with more context-aware routing, prioritization, and retry behavior without discarding the deterministic reliability principles that made message queues useful in the first place.

Explore the implementation: 👉 AI-Assisted Message Queue Patterns on GitHub

The examples in this series are architectural patterns and reference implementations intended for experimentation and learning. Production systems should independently evaluate model behavior, security, latency, cost, failure modes, and workload-specific requirements.

AI Should Recommend, Policy Should Decide - Guardrails for Production Messaging Systems

Sarath Kumar Kallayil Sreedharan — Wed, 26 Aug 2026 16:47:29 +0000

This is Part 2 of the AI-Assisted Message Queue Patterns series. Part 1 introduced the architecture: SQS → consumer → context → AI recommendation → deterministic policy → action. This article focuses on the boundary that makes that architecture practical: what the model may recommend, what policy must control, and what happens when the model is uncertain, unavailable, or wrong.

The model call is the easy part

Calling a model from a Lambda function is not the difficult architectural problem.

The difficult problem starts after the model responds.

Suppose a message-processing application receives this recommendation:

{
  "priority": "HIGH",
  "route": "PROCESSOR_B",
  "retry": true,
  "retry_delay_seconds": 120,
  "confidence": 0.91
}

What should happen next?

A naive implementation might execute the response directly. That creates an uncomfortable amount of authority for a probabilistic component. The model can produce malformed output. It can recommend a destination that does not exist. It can return a retry interval outside the application's operating limits. It can be unavailable entirely.

The safer architecture is:

Message
   ↓
Context
   ↓
AI Recommendation
   ↓
Validate
   ↓
Apply Policy
   ↓
Execute Approved Action

The principle from Part 1 remains:

AI recommends. Policy decides. The messaging platform executes.

Start with an explicit decision contract

Before invoking a model, define what a valid recommendation actually looks like. For example:

{
  "priority": "HIGH | STANDARD",
  "route": "PROCESSOR_A | PROCESSOR_B",
  "retry": true,
  "retry_delay_seconds": 120,
  "confidence": 0.91,
  "reason": "Short explanation"
}

This is intentionally constrained. The model is not being asked "What should I do with this infrastructure?" It is being asked to choose among a bounded set of actions the application already understands.

That distinction reduces the problem from unrestricted generation to constrained decision support.

Guardrail 1: Validate structure before meaning

Never assume that because you asked for JSON, you received usable JSON. A response can be malformed, missing required fields, wrong types, outside an allowed enum, or syntactically valid but operationally impossible.

Validation should happen before the recommendation reaches execution logic.

def validate_decision(decision):
    required = ["priority", "route", "confidence"]

    for field in required:
        if field not in decision:
            return False

    if decision["priority"] not in {"HIGH", "STANDARD"}:
        return False

    if decision["route"] not in ALLOWED_ROUTES:
        return False

    if not 0 <= decision["confidence"] <= 1:
        return False

    return True

If validation fails:

Invalid model response
        ↓
Deterministic fallback

Not:

Invalid model response
        ↓
Best guess

Guardrail 2: Policy before execution

A valid response is not automatically an allowed response. Imagine the model returns:

{
  "route": "PROCESSOR_B",
  "confidence": 0.97
}

High confidence does not grant permission. Policy still needs to answer: Is PROCESSOR_B an approved destination? Is this workload allowed to use it? Does the message satisfy required constraints? Is routing there currently enabled? Does the action violate any workload-specific rule?

The model should operate inside a policy-defined action space.

if recommendation["route"] not in ALLOWED_ROUTES:
    return deterministic_route(message)

return recommendation["route"]

For more complex routing, policy should filter invalid candidates before optimization or scoring whenever possible:

Candidate destinations
        ↓
Security / residency / workload policy
        ↓
Allowed candidates only
        ↓
Contextual scoring or recommendation
        ↓
Validated selection

This is stronger than asking a model to consider forbidden options and hoping it remembers not to select them.

Guardrail 3: Confidence gating

The reference pattern uses a configurable threshold such as:

MIN_CONFIDENCE=0.7

if recommendation["confidence"] < MIN_CONFIDENCE:
    return deterministic_fallback(message)

But there is an important nuance. An LLM-generated value of 0.91 should not automatically be interpreted as a calibrated 91% probability of correctness. Unless confidence has been independently calibrated and evaluated, treat it as a decision signal, not statistical truth.

The threshold is application policy:

Recommendation
      ↓
Confidence acceptable?
   /             \
 No               Yes
 ↓                 ↓
Fallback        Continue

Confidence gating becomes more useful when combined with validation, policy constraints, and observed performance.

Guardrail 4: Deterministic fallback is a first-class path

Fallback should not be emergency code that nobody tests. It should be a normal operating mode.

In the reference implementation, the architecture supports:

USE_BEDROCK=false

so the message-processing path can operate without model access.

if not USE_BEDROCK:
    return deterministic_decision(message)

try:
    recommendation = invoke_model(context)
except Exception:
    return deterministic_decision(message)

The same fallback can be used when Bedrock is unavailable, invocation times out, the response is malformed, policy rejects the recommendation, or confidence is below threshold.

That creates a useful invariant: loss of AI capability should not automatically mean loss of messaging capability.

Guardrail 5: Bound retry recommendations

Adaptive retry is useful only if the model cannot invent unbounded retry behavior. Suppose the model recommends:

{
  "retry": true,
  "retry_delay_seconds": 7200,
  "confidence": 0.92
}

The application may allow only:

MIN_RETRY_DELAY = 30 seconds
MAX_RETRY_DELAY = 900 seconds
MAX_ATTEMPTS = 5

Policy wins:

delay = max(
    MIN_RETRY_DELAY,
    min(recommendation["retry_delay_seconds"], MAX_RETRY_DELAY)
)

if attempt >= MAX_ATTEMPTS:
    send_to_dlq(message)

Failure class should matter as well. A useful deterministic baseline is:

Transient failure      → Bounded retry + backoff
Permanent failure      → DLQ / terminal handling
Ambiguous failure      → Limited retry → Re-evaluate

AI can help classify ambiguous context, but it should not remove hard retry boundaries.

Guardrail 6: Preserve idempotency

AI does not change a fundamental property of queue consumers: messages can be processed more than once. Any side-effecting consumer should therefore remain idempotent.

A useful pattern is to derive an idempotency key from the producer's stable event identifier and record whether the operation has already completed.

Receive message
      ↓
Check idempotency key
   /             \
Seen             New
 ↓                ↓
Skip          Process
                 ↓
             Record result

Adaptive routing and retry make idempotency more important, not less. A message that changes processing paths must still represent the same logical event.

Guardrail 7: Avoid unstable decisions

Context changes. If the decision engine continuously reacts to tiny changes in queue depth, latency, or health signals, routing can oscillate:

Processor A → Processor B → Processor A → Processor B

That is not intelligence. It is instability.

Useful stability controls include minimum dwell time, hysteresis, rate limits, confidence thresholds, and bounded decision frequency. For example, don't change routes merely because Processor B is 2% healthier for one observation — require a meaningful difference for a sustained period.

New recommendation
       ↓
Materially better?
       ↓
Stable long enough?
       ↓
Policy allows change?
       ↓
Switch

Guardrail 8: Make the decision explainable

For every AI-assisted operational decision, record enough information to reconstruct why it happened:

{
  "message_id": "evt-4821",
  "decision": "PROCESSOR_B",
  "decision_source": "bedrock",
  "confidence": 0.91,
  "fallback_used": false,
  "policy_version": "v3",
  "reason": "Processor A degraded; B is approved and healthy"
}

For routing decisions, also consider recording candidate routes, candidates removed by policy, relevant health/context signals, the selected destination, fallback rationale, model/version identifier, and decision latency.

Observability should answer why did this message take this path? without requiring someone to reproduce the model invocation after an incident.

Guardrail 9: Separate model failure from workload failure

These are different events: model invocation failed and downstream processing failed. Do not collapse them into the same metric.

Track at least:

AI invocation success/failure
AI decision latency
Fallback rate
Low-confidence rate
Policy rejection rate
Message-processing success/failure
Retry count
DLQ count

A system can have a healthy model path while the workload is failing, or a failing model path while deterministic processing remains healthy. Operational dashboards should make that distinction visible.

A practical decision flow

Putting the pieces together:

Incoming Message
       ↓
Build Context
       ↓
Is AI enabled? ──No──→ Rules
       │Yes
       ↓
Invoke Model
       ↓
Invocation OK? ──No──→ Rules
       │Yes
       ↓
Parse + Validate
       ↓
Valid? ──No──→ Rules
       │Yes
       ↓
Policy Check
       ↓
Allowed? ──No──→ Rules
       │Yes
       ↓
Confidence Gate
       ↓
Above threshold? ──No──→ Rules
       │Yes
       ↓
Approved Action ──→ Execute

The deterministic path is not separate from the architecture. It is part of the architecture.

What I would test before enabling AI decisions

Before allowing recommendations to affect real message paths, test the system against cases such as:

Scenario	Expected behavior
Bedrock unavailable	Deterministic fallback
Model timeout	Deterministic fallback
Invalid JSON	Deterministic fallback
Unknown route	Reject and fall back
Confidence below threshold	Deterministic fallback
Retry delay above maximum	Clamp/reject per policy
Maximum attempts reached	Terminal handling / DLQ
Duplicate message	Idempotent processing

I would also run the model in shadow mode before giving its recommendations operational effect:

Message
   ↓
Existing deterministic decision ──────► Production action
   ↓
AI recommendation
   ↓
Record only

Then compare: How often did AI agree with existing logic? Where did it disagree? Were disagreements useful? What was fallback frequency? What latency and cost did the model add? Which recommendation categories performed poorly?

Only after measuring those results would I expand operational authority.

The goal isn't maximum AI

A successful design is not the architecture that invokes AI most often. It's the architecture that uses AI where contextual reasoning provides measurable value while keeping deterministic behavior where deterministic behavior is already sufficient.

That may mean 80% deterministic / 20% AI-assisted, or 99% deterministic / 1% AI-assisted. The right percentage depends on the workload.

The principle doesn't change regardless of that ratio:

AI recommends. Policy decides. The messaging platform executes.

What's next

Part 1 introduced the architecture. This article defined the guardrails around it. Part 3 turns those ideas into an implementation using Amazon SQS, AWS Lambda, Amazon Bedrock, and AWS SAM: queues, functions, model invocation, structured decisions, deterministic mode, routing, priority scoring, retry handling, deployment, and testing.

The reference implementation is available here: AI-Assisted Message Queue Patterns on GitHub

When AI Meets the Message Queue: Building Intelligent Routing with Amazon Bedrock and SQS

Sarath Kumar Kallayil Sreedharan — Tue, 25 Aug 2026 19:07:14 +0000

This is Part 1 of a series on adding AI-assisted decision-making to event-driven messaging systems. The architecture grew out of my ACM Summer Tech Talk on intelligent message routing and prioritization, and this article introduces the open-source reference implementation used throughout the series.

The problem with static routing logic

Most event-driven systems make the same handful of decisions repeatedly using deterministic rules.

That's often the right design — until those decisions start depending on context that changes faster than the rules do.

A message shows up. Some code decides:

Which processing path it belongs in
How urgently it needs to be processed
What to do if processing fails

Traditionally, those decisions are implemented with fixed logic:

SQS → Consumer/Lambda → Fixed Logic → Process/Retry → DLQ

That logic might be a collection of if/elif statements, lookup tables, message attributes, or routing policies based on conditions known when the system was designed.

And for many workloads, that's exactly what you want.

If a decision can be expressed reliably with a few deterministic rules, an AI model probably shouldn't be involved.

The challenge appears when decisions depend on broader and continuously changing context.

What does "high priority" mean when a downstream dependency is degraded? Should two failures with completely different causes receive the same retry treatment? Should a message continue down its normal processing path when another approved processor is healthier?

Static rules can handle these scenarios, but as the number of contextual signals grows, the decision tree can become increasingly complex to maintain.

That's where AI-assisted decision-making becomes interesting.

Where contextual decision-making can help

There are three areas I wanted to explore.

Routing. Traditional routing often maps known message types to predetermined destinations:

Message Type A → Processor A
Message Type B → Processor B

But the appropriate processing path may depend on more than the message type. Message characteristics, downstream availability, workload conditions, or other operational context may also matter.

Prioritization. Priority is frequently encoded as a fixed message attribute or determined using predefined business rules. But urgency can sometimes depend on context. A message that is routine under normal operating conditions may deserve different treatment when the system is experiencing an incident, backlog, or downstream degradation.

Retry behavior. Failures are also not identical. A transient downstream timeout and a permanently invalid request should not necessarily receive the same retry strategy. Repeatedly retrying a request that is unlikely to succeed can waste resources, while retrying too slowly after a transient failure can unnecessarily increase recovery time.

The question becomes: can we use additional context to make better recommendations while preserving deterministic control over what the system actually does?

An AI-assisted approach

The architecture I explored does not replace deterministic rules with AI. Instead, it introduces AI as a decision-support layer.

SQS
 ↓
Lambda / Consumer
 ↓
Context Builder
 ↓
Amazon Bedrock
 ↓
AI Recommendation
 ↓
Policy Guardrails
 ↓
Action

One important distinction: Amazon Bedrock does not poll SQS or control the queue. In a Lambda-based implementation, the SQS event source mapping handles polling and invokes the Lambda consumer. The application builds the relevant context and invokes the model. The model participates in the decision, not the queue mechanics.

A decision request might contain information such as:

{
  "message_type": "service_interruption",
  "message_age_seconds": 45,
  "attempt": 2,
  "queue_backlog": 4200,
  "downstream_health": "degraded",
  "workload_tier": "critical"
}

The decision layer can return a structured recommendation such as:

{
  "priority": "HIGH",
  "route": "PROCESSOR_B",
  "retry_delay_seconds": 120,
  "confidence": 0.93
}

The application does not blindly execute that response. It validates the recommendation against deterministic policy first.

The principle that makes this practical

The entire pattern can be summarized in one sentence:

AI recommends. Policy decides. The messaging platform executes.

That separation is important. The model never receives unrestricted operational authority. Its recommendation passes through deterministic guardrails controlling things such as:

Allowed routing destinations
Valid priority levels
Maximum retry attempts
Bounded retry delays
Minimum confidence thresholds
Workload-specific restrictions
Fallback behavior

If a recommendation violates policy, the application rejects it. If the model isn't available, the application falls back. If the response isn't valid, the application falls back. If the confidence indicator is below the configured threshold, the application falls back.

That's not a limitation bolted on as an afterthought. It's the design.

Pattern 1: Content-aware routing

Suppose the normal routing logic looks like this:

Message Type A → Processor A
Message Type B → Processor B

Now imagine that routing depends on additional context:

Message characteristics
        +
Processing requirements
        +
Downstream health
        +
Operational conditions
        ↓
   Routing Decision

Instead of expanding a static decision tree indefinitely, the consumer can provide that context to the AI decision layer. The model might recommend:

{
  "route": "PROCESSOR_B",
  "confidence": 0.94
}

But the recommendation still goes through policy:

if decision["route"] not in ALLOWED_ROUTES:
    route = DEFAULT_ROUTE
else:
    route = decision["route"]

Bedrock recommends PROCESSOR_B. The application determines whether PROCESSOR_B is permitted. The messaging layer executes the validated routing decision.

Pattern 2: AI-assisted priority scoring

Consider two messages.

Message A — Type: Account update. Age: 2 seconds. Workload tier: Standard. Queue backlog: Low.

Message B — Type: Service interruption. Age: 45 seconds. Workload tier: Critical. Queue backlog: High. Downstream risk: Elevated.

A fixed priority rule might only examine the message type. A context-aware decision layer can consider multiple signals and recommend an urgency level:

{
  "priority": "HIGH",
  "reason": "Critical workload with elevated downstream risk",
  "confidence": 0.95
}

The application validates that recommendation and selects the appropriate processing path.

Priority itself is not implemented through an SQS visibility timeout. Visibility timeout controls how long a received message remains hidden from other consumers while it is being processed. In the reference implementation, different processing paths can have their own operational queue configuration, but queue selection represents prioritization; visibility timeout is a separate reliability configuration.

Pattern 3: Adaptive retry and backoff

Retry behavior becomes particularly interesting when additional failure context is available. An adaptive decision can consider error category, previous attempts, downstream health, queue backlog, message urgency, and historical failure context.

It might recommend:

{
  "retry": true,
  "retry_delay_seconds": 180,
  "confidence": 0.89
}

Or:

{
  "retry": false,
  "route": "FALLBACK_PROCESSOR",
  "confidence": 0.94
}

The model is recommending a retry strategy. Deterministic policy still enforces maximum attempts, allowed retry intervals, maximum delay, approved fallback destinations, and DLQ behavior.

The AI layer therefore does not replace SQS reliability mechanisms. It adds contextual decision support around them.

Confidence is a gate, not authority

The model response also includes a structured confidence indicator. That value should not be interpreted as a statistically calibrated probability of correctness unless you've specifically built and validated it that way.

In this pattern, it serves a simpler purpose: it's one input into the application's acceptance policy.

if decision["confidence"] < MIN_CONFIDENCE:
    use_deterministic_fallback()
elif decision["route"] not in ALLOWED_ROUTES:
    use_default_route()
else:
    execute_validated_decision(decision)

In the reference implementation, responses below MIN_CONFIDENCE are rejected in favor of deterministic behavior.

What happens when Bedrock is unavailable?

The system should never become:

Bedrock unavailable
        ↓
Messaging stops

If Bedrock is unavailable, times out, returns malformed output, or produces a recommendation that doesn't satisfy policy, the application falls back to deterministic processing. The queue continues operating. The consumer continues processing. Existing retry and DLQ mechanisms remain available.

AI should enhance the system, not become a new single point of failure.

Should every message invoke an AI model?

Probably not.

Model invocation introduces additional considerations: latency, cost, throughput, quotas, availability, and operational complexity. A practical architecture can use AI selectively. Simple decisions stay deterministic. AI is reserved for situations where additional context provides enough value to justify the model invocation.

A working reference implementation

I built this architecture as an AWS SAM reference application: ai-message-queue-patterns.

It uses Amazon SQS, AWS Lambda, and Amazon Bedrock, and combines three related patterns into one message-processing pipeline.

Pattern	What it does
Content-Aware Routing	Bedrock evaluates message context and recommends a downstream destination; deterministic policy validates the recommendation before routing.
AI-Assisted Priority Scoring	Evaluates message context and recommends an urgency level used to select the appropriate processing path.
Adaptive Retry & Backoff	On failure, classifies the failure context and recommends a retry strategy; deterministic policy enforces attempt limits, delay bounds, and DLQ behavior.

A few implementation choices are particularly important.

Deterministic mode. Setting USE_BEDROCK=false allows the pipeline to operate using deterministic fallback logic without depending on model access. The messaging system doesn't have to depend on AI in order to function.

Confidence gating. The implementation uses a configurable threshold: MIN_CONFIDENCE=0.7. Recommendations below that threshold are rejected in favor of deterministic fallback. The threshold isn't proof that a recommendation is correct; it's an application policy controlling when the system is willing to consider the model's output.

Independent patterns. The Router, Priority Scorer, and Retry Handler are separate components. That means adopting this architecture doesn't require committing to every pattern at once.

Lambda isn't required. Although the reference implementation uses Lambda, the architecture isn't Lambda-specific. A consumer could run on AWS Lambda, Amazon EC2, Amazon ECS, Amazon EKS, or another application runtime. The architectural principle remains unchanged: the application invokes the AI decision engine. The AI model does not replace the messaging infrastructure.

The bigger pattern

Traditional automation often looks like this:

Event → Rule → Action

AI-assisted automation introduces another possibility:

Event → Context → AI Recommendation → Policy → Action

Adding AI doesn't eliminate deterministic engineering. If anything, it makes deterministic engineering more important.

Once a probabilistic component becomes part of a production decision path, the boundaries around that component need to become explicit:

What is the model allowed to recommend?
What is it never allowed to decide?
What happens when it's wrong?
What happens when it's unavailable?
When should we avoid invoking it altogether?

For message-driven systems, routing, prioritization, and retry are three interesting places to explore contextual AI-assisted decision-making. But the architectural principle stays deliberately simple:

AI recommends. Policy decides. The messaging platform executes.

What's next

This article covered the architecture and the reasoning behind it. Part 2 will go deeper into policy guardrails, confidence thresholds, deterministic fallback, malformed model responses, and failure modes. After that, I'll walk through the implementation itself using the open-source repository.

If you want to explore the code now: 👉 AI-Assisted Message Queue Patterns on GitHub

The examples in this article are architectural patterns and reference implementations intended for experimentation and learning. Production systems should evaluate model behavior, latency, cost, security, failure modes, and workload-specific requirements before introducing AI-assisted decision-making into critical processing paths.