Video summary

Building Agentic AI with AWS Serverless & Why Facilitation is the SA Superpower

Main summary

Key takeaways

Technology

Video topic

The session explains how to build agentic AI architectures using AWS serverless, why serverless fits spiky/bursty workloads, and how facilitation (asking better questions, driving ownership) is key to being an effective “SA superpower.” It ends with a workshop walkthrough for hands-on labs.

1) Building agentic AI with AWS serverless (technical concepts + architecture)

Why serverless for agentic workloads

  • Serverless is presented as a good fit for unpredictable, spiky, bursty, intermittent AI workloads.
  • Core cost model: pay only when executing, avoiding charges for idle infrastructure.
  • Clarification:
    • “Serverless” does not mean “no servers.” It means infrastructure is abstracted away from the developer.
    • Auto-scaling can handle 1 request to 10,000+ elastically.

Key AWS services mentioned for serverless agentic systems (partial list)

  • AWS Lambda: event-driven compute (“Swiss army knife”)
  • Amazon Bedrock: foundation models and managed model serving
  • Amazon SageMaker: includes serverless inference for custom models
  • Bedrock Agent Core: runtime features like memory, tool calling, and orchestration-related capabilities
  • Amazon EventBridge: event routing/coordination triggers
  • AWS Step Functions: orchestration/workflow manager
  • AWS IoT Greengrass / edge deployment: run inference closer to devices/users (edge)
  • Edge locations: execute functions/models near end users for latency/connectivity needs

Core principles (5 fundamentals) for serverless AI architecture

The architecture is framed around five design questions:

  1. What starts the system? (events: human/system/scheduled triggers)

  2. Who coordinates the work? (orchestration: rule-based or AI-driven)

  3. Where does intelligence come from? (LLM/model location: cloud/on-prem/edge)

  4. What is the trusted context? (grounding/RAG so answers use correct domain/org data)

  5. Where does inference run? (cloud vs edge based on latency, data location, model size)

Events + event-driven architecture (EDA)

  • Agents aren’t running continuously; they “wake up” via events.
  • Event sources can include:
    • user actions (button click),
    • system outputs (new message, updated data),
    • schedules (e.g., backups at a time),
    • sensor thresholds (analogy: fire alarm / AC threshold).
  • Events can chain: one event triggers another system/agent.

Orchestration: rule-based + AI-native together

  • Orchestration decides what happens next after an agent starts.
  • It can be:
    • predefined workflow/rules for deterministic steps, and/or
    • AI-native dynamic decisions when context requires reasoning.
  • The system can mix both: rules for some steps, model calls for others.

Custom vs foundation models in a serverless workflow

  • Using custom models does not break “serverless.”
  • Two serverless-ish paths:
    1. Bedrock for common foundation models (managed, pay-per-use)
    2. SageMaker serverless inference for custom/fine-tuned models
  • Example pattern:
    • Bedrock agent does triage reasoning, then calls a custom model (SageMaker), then returns final output (potentially looping across multiple model calls).

Grounding / RAG (retrieval augmented generation)

  • Grounding makes the model domain-specific using enterprise/private data.
  • Mechanism:
    • retrieve relevant documents (e.g., from S3/knowledge bases),
    • feed them to the model so it can:
      • avoid hallucinations,
      • answer within correct policy/context,
      • include citations/references to retrieved sources.
  • Analogy: a lawyer uses references/books only when needed.
  • Without grounding: answers are generic and may not know facts like “today’s temperature for my location” or “my company leave policy.”

Inference placement: cloud vs edge

  • Driven by:
    • latency requirements
    • connectivity
    • model size
    • where data is generated
  • Edge examples:
    • smart car must decide immediately (no cloud round-trip),
    • factory anomaly detection needs instant action.
  • Cloud examples:
    • heavier reasoning/efficiency comparisons,
    • larger models requiring more compute.

Layered view of an agentic AI system

Mapped as a layered architecture (agentic variant):

  • Event layer (triggers: API/event-driven input)
  • Pre-processing layer (format prompts so models can use them)
  • Inference/intelligence layer (model execution; includes RAG during this phase)
  • Post-processing/decision layer (format responses for humans + enforce policy/approval)
  • Output/storage layer (persist results; knowledge base/data store)

Use case example: retail customer service agent / returns

  • Event: customer submits a return request.
  • Pre-processing: interpret intent, transform inputs for the model.
  • Inference/RAG: check order status + retrieve return policy; determine eligibility.
  • Post-processing: approve or deny refund claim based on conditions.
  • Output: send response and store results (e.g., S3).

Design considerations across all layers

Cross-cutting concerns emphasized at every layer:

  • resilience
  • observability
  • security
  • cost optimization
  • extensibility

(They should not be treated as add-ons later.)

External reference mentioned

  • A link to a blog post about a real KYC (Know Your Customer) architecture, showing how an end-to-end serverless solution can be built (including potential integrations like on-prem connectivity).

2) Behavioral track: “Why facilitation is the SA superpower” (key takeaways)

Core message

  • Good Solution Architect sessions create outcomes through facilitation, not monologuing.
  • Expertise matters, but delivering it as a monologue can become information transfer, while facilitation creates ownership, discussion, and relationships.

Presenter trap pattern

  • Build huge decks (example: 47 slides, 45-minute monologue).
  • Audience nods politely; few questions.
  • Outcome: customer asks for slides and goes silent (“radio silence”), delaying decisions.

Facilitation pattern contrast

  • Use fewer slides (example: 4 slides) as discussion starters.
  • Lead with questions so customers talk themselves into a strategy.
  • Example outcome described:
    • customer leadership aligned on modernization strategy and committed to funding/workload priorities during the session.

“Three mental shifts” for facilitation

  1. Don’t be the smartest person in the room: make the room smart
    • Presenter metric: “Did I cover all slides?”
    • Facilitator metric: “Did the room reach a decision?”

  2. Decisions happen when people verbalize (commitment forms when stated aloud)

  3. Value is in asking questions, not providing answers (since content is easy to look up, facilitation is harder—and more valuable)

Reframing “please present” requests

Instead of saying “no,” reframe as:

  • a working session that drives decisions/commitments,
  • a prioritization exercise (success criteria/workback),
  • or collaboration between teams to resolve operating-model issues.

Costs of not changing

  • Gradual “slow fade” from being invited to decision sessions to being seen as nice-to-have.
  • Facilitation builds trust/partnership; presenter mode can become transactional.

Homework suggestion

  • Replace the opening slide with a well-crafted question that forces success-definition.
  • Workshop it internally with trusted peers beforehand.
  • Lead with curiosity and listen for verbal commitment.

3) Hands-on workshop walkthrough (technical lab details)

Workshop purpose

Build agents using Lambda and serverless services:

  • Step Functions
  • EventBridge
  • SQS
  • SNS

Focus patterns:

  1. Choreography pattern
  2. Orchestration pattern

Choreography vs orchestration (how agents coordinate)

  • Choreography: multiple agents act independently via event-driven communication, loosely coupled.
  • Orchestration: a central coordinator decides when to call different agents.

Agentic loop concept refresher

Agent loop:

  • observe/context → reason → decide to act → select tools (tool selection via model/LLM) → run tools → update context → repeat until goal reached.

Workshop demo application

  • Example app: travel planner assistant
    • plan itinerary,
    • check weather and flight routes,
    • human approval step (or auto approval).

Tooling/SDK

  • Agents built in Lambda using Strand(s) SDK (light Python SDK).
  • Strand SDK handles:
    • agent logic,
    • reasoning/tool selection flow,
    • response parsing,
    • session management assistance.

What participants do in the lab (choreography part)

  • Agents/Lambda functions are pre-created (e.g., “planner”, “weather”, “flight manager”).
  • Participants weave them together by creating EventBridge rules.
  • Steps include:
    • creating rules with JSON event pattern matching,
    • setting rule targets so planner triggers other agents in parallel,
    • checking EventBridge rules/permissions and Lambda policies.

Debugging + logs (important guidance)

  • Check Lambda logs in CloudWatch Logs (logs group or console under monitoring/logs).
  • Logs may appear only after waiting a few minutes.

Common gotchas explicitly called out

  • CLI variable placeholders (e.g., booking ID must be replaced; use correct timestamps window).
  • Optional SNS email notifications:
    • confirm the subscription, since spam/junk can hide messages.
  • Human approval gating:
    • sometimes no logs appear until a human approval decision step is performed in the choreography sequence.

Workshop access/logistics (workflow)

  • Workshop must be pre-registered with a business email.
  • Quiz access differs from workshops (uses a separate platform URL).
  • If not registered, you can watch walkthrough videos but can’t provision the workshop in your own account.

Main speakers / sources

  • Ashish (AWS expert/host for the agentic AI + serverless architecture technical session)
  • Krishna (customer persona; asks technical questions during the serverless + agentic AI discussion)
  • Jeff Escott (AWS Principal Architect; facilitation/behavior track)
  • Nisha Diktavala (AWS Senior Solution Architect; co-leads facilitation discussion)
  • Anmul (Amul) and Pera/Perna (Pera/Perna) (workshop walkthrough / hands-on lab guidance)
  • Prasad, Anmul/others (additional participants/support for logistics and workshop access coordination)

Original video