DEV Community: Alejandro Hernández

Your Prompt Is Not an Architecture: Event-Driven Serverless Agents

Alejandro Hernández — Thu, 01 Oct 2026 17:33:39 +0000

In the previous article,
I proposed a simple idea: agents don't start with prompts; they start
with events.

Most current conversations about agents begin in the wrong place. They
begin with a prompt, an LLM, a list of tools, and a final response. That
model can be useful, but it doesn't fully describe how many real systems
behave in production.

Most agent frameworks start with the prompt. This architecture starts
with the event.

While many frameworks model agents as conversations, this architecture
models them as event-driven control systems.

A business process doesn't begin because someone wrote a prompt. It
begins because something happened: a candidate applied for a job, a
customer sent an email, a document was uploaded, a payment was approved,
or an order changed status. The event is the trigger. The prompt, when
one exists, comes later.

In this article, I want to turn that idea into a concrete architecture.
If we define an agent as a system that observes events, evaluates
information, and executes actions, then we can build it as an
event-driven control loop.

And that loop fits serverless extremely well.

We don't need to imagine the agent as a living process thinking all day.
We can build it as a set of small Lambdas that wake up when something
happens, consult durable memory, make decisions, and emit new events.

Not:

prompt -> LLM -> tool -> response

Instead:

event -> collect -> correlate -> evaluate -> emit -> action -> event

The LLM can participate. In fact, it will often be a very powerful tool
inside the process. But it isn't the center of the architecture.

The control loop is.

Control services as an implementation pattern

Let's use the example from the previous article: recruiting.

When someone applies for a job, the system doesn't need to "wait for a
prompt." A relevant fact has already occurred:

CandidateApplied

From there, many other events may happen:

CandidateApplied
        ↓
ResumeAnalyzed
        ↓
InterviewScheduled
        ↓
InterviewCompleted
        ↓
FeedbackReceived
        ↓
OfferSent

The interesting question is: where is the agent?

It isn't only in the resume analysis. It also isn't only an LLM
producing a recommendation. The agent is the complete system that
observes the process, accumulates evidence, evaluates the current state,
and generates new facts to move things forward.

In a serverless architecture, control-service patterns fit this way of
building event-driven agents very well.

A control service observes lower-level events, maintains operational
memory, and produces higher-level events. That doesn't mean every agent
must be a control service. It means this pattern gives us a natural way
to implement event-driven agents in production.

Lower-level events describe things that happened:

CandidateApplied
ResumeUploaded
ResumeAnalyzed
InterviewCompleted
FeedbackReceived

Higher-level events represent derived conclusions or intentions:

CandidateQualified
InterviewRequested
HumanReviewRequired
OfferRecommended
CandidateRejected

The agent lives in the transition between the two.

The architecture

To make this concrete, imagine a recruiting agent that answers a limited
question:

When a candidate applies for a job, do we have enough information to
recommend the next step?

We're not building a complete ATS (Applicant Tracking System). We're
also not automating the final hiring decision. That's not the point.

The point is to show how an agent can:

observe an application;
store the event;
correlate it with the candidate, job, and application;
request resume analysis;
use an LLM for a specific task;
evaluate the result;
emit an intention for the next step.

This architecture uses managed serverless services for what they do
best:

EventBridge routes business events.
SQS or Kinesis decouple producers and consumers.
Lambda executes small pieces of logic.
DynamoDB stores events and correlations.
DynamoDB Streams wakes up the next control-loop iteration.

The agent doesn't need to run all the time. It waits for events.

For the examples, I'll use
modmex-lambda, a library
for building 100% serverless cloud-native applications on AWS Lambda
with Python. It supports synchronous services such as API Gateway APIs
as well as asynchronous services for event-driven architectures.

The part we're interested in here is modmex_lambda.stream: the module
for building event-driven pipelines with sources, rules, and flavors
such as Collect, Correlate, Evaluate, Expired, and Task.

It isn't a prompt-based agent framework. It's a small layer for
implementing control patterns over events: normalizing AWS events,
executing rules, persisting or querying DynamoDB, and publishing new
events to EventBridge.

The minimum event contract

Before talking about prompts or models, we need to talk about events.

An application event might look like this:

{
  "id": "candidate-applied-001",
  "type": "candidate.applied",
  "timestamp": 1718050000000,
  "partition_key": "application-789",
  "application": {
    "id": "application-789",
    "status": "submitted",
    "resume_s3_key": "resumes/johndoe.pdf",
    "candidate": {
      "id": "candidate-123",
      "name": "John Doe",
      "email": "johndoe@example.com"
    },
    "job": {
      "id": "job-456",
      "title": "Backend Engineer",
      "required_skills": ["python", "aws", "serverless"]
    }
  }
}

A few fields matter:

id: unique event identity.
type: what happened.
timestamp: when it happened.
partition_key: the natural key for distribution and correlation.
application: the domain entity associated with the event.

This convention matters. Events are normally emitted around a domain
entity. If the event is candidate.applied, the primary entity may be
application; if the event is resume.analyzed, the primary entity may
still be application, now enriched with the analysis.

An event shouldn't be only a minimal notification. Downstream services
often need enough information to react without coupling themselves back
to the producer. That's why the canonical entity can contain snapshots
of related data such as the candidate and job.

The control service can also enrich that entity when it emits
higher-level events. For example, it can take an application received
from a core service and emit another application containing
analysis, recommendation, and next_step.

This contract matters more than it may seem. If events are poor, the
agent has nothing meaningful to observe. If events are ambiguous, the
agent can't explain why it acted. If events don't have correlation keys,
the agent can't build context.

The agent's memory doesn't have to live in an LLM context window. It
can live in durable events.

Collect: observing facts

The first step in the loop is Collect.

Collect doesn't decide anything. It doesn't call the LLM. It doesn't
send emails. It doesn't schedule interviews.

Its responsibility is simpler and more important: take an observed event
and store it as a durable fact.

With modmex-lambda, a Lambda can consume messages from SQS and
register the events in DynamoDB:

from modmex_lambda.stream.flavors.collect import Collect
from modmex_lambda.stream.rules_registry import RulesRegistry
from modmex_lambda.stream.sources.sqs import sqs_source

listener_registry = RulesRegistry().registry(
    Collect({
        "id": "collect-candidate-events",
        "event_type": [
            "candidate.applied",
            "resume.analyzed",
            "interview.completed",
            "feedback.received",
        ],
        "correlation_key": "application.id",
        "table_name": "RecruitingEvents",
        "include_raw": True,
    })
)

@sqs_source(listener_registry, concurrency=True)
def handler(event, context):
    return {"statusCode": 200}

sqs_source adapts the AWS event into a standard unit of work.
RulesRegistry registers the pipelines that should execute. Collect
filters by event_type, calculates a correlation key, and writes to
DynamoDB.

Conceptually, the persisted item looks like this:

{
  "pk": "candidate-applied-001",
  "sk": "EVENT",
  "discriminator": "EVENT",
  "timestamp": 1718050000000,
  "data": "application-789",
  "event": {
    "id": "candidate-applied-001",
    "type": "candidate.applied",
    "partition_key": "application-789"
  }
}

This turns a transient event into operational memory.

From here, DynamoDB Streams can wake up the next step of the loop.

Correlate: building context

An isolated event is rarely enough to make a decision.

A candidate can have multiple applications. A job can have many
candidates. An application can accumulate analysis, interviews,
feedback, and approvals. That's why we need correlation.

Correlate takes events that have already been stored and rewrites
references under alternative keys. It doesn't duplicate business
reality; it creates efficient ways to query context.

Original event:
pk=candidate-applied-001, sk=EVENT

Correlations:
pk=application-789.application, sk=candidate-applied-001
pk=candidate-123.candidate, sk=candidate-applied-001
pk=job-456.job, sk=candidate-applied-001

With modmex-lambda, we can declare those correlations like this:

from modmex_lambda.stream.flavors.correlate import Correlate
from modmex_lambda.stream.rules_registry import RulesRegistry
from modmex_lambda.stream.sources.dynamodb import dynamodb_source

trigger_registry = RulesRegistry().registry(
    Correlate({
        "id": "correlate-by-application",
        "event_type": ["candidate.applied", "resume.analyzed", "interview.completed", "feedback.received"],
        "correlation_key": "application.id",
        "correlation_key_suffix": "application",
        "table_name": "RecruitingEvents",
    }),
    Correlate({
        "id": "correlate-by-candidate",
        "event_type": ["candidate.applied", "resume.analyzed", "interview.completed", "feedback.received"],
        "correlation_key": "application.candidate.id",
        "correlation_key_suffix": "candidate",
        "table_name": "RecruitingEvents",
    }),
    Correlate({
        "id": "correlate-by-job",
        "event_type": ["candidate.applied", "resume.analyzed", "interview.completed", "feedback.received"],
        "correlation_key": "application.job.id",
        "correlation_key_suffix": "job",
        "table_name": "RecruitingEvents",
    }),
)

@dynamodb_source(trigger_registry, concurrency=True)
def handler(event, context):
    return {"statusCode": 200}

This trigger isn't listening directly to the ATS. It listens to the
DynamoDB stream.

candidate.applied
        ↓
Collect → pk=candidate-applied-001, sk=EVENT
        ↓
DynamoDB Streams
        ↓
Correlate
        ↳ pk=application-789.application, sk=candidate-applied-001
        ↳ pk=candidate-123.candidate, sk=candidate-applied-001
        ↳ pk=job-456.job, sk=candidate-applied-001

Now the agent can answer different questions:

What do we know about this application?
What do we know about this candidate?
What's happening with this job?

Without correlation, the agent only reacts. With correlation, it can
evaluate with context.

Evaluate: making decisions

Evaluate is where the decision lives. It can emit a higher-level event
directly, or query correlated events before deciding.

If an application arrives with a resume, we want to request an analysis:

from pydash import get
from modmex_lambda.stream.flavors.evaluate import Evaluate

trigger_registry.registry(
    Evaluate({
        "id": "request-resume-analysis",
        "event_type": "candidate.applied",
        "correlation_key_suffix": "application",
        "expression": lambda uow: bool(get(uow, "event.application.resume_s3_key")),
        "emit": lambda uow, rule, template: {
            **template,
            "type": "resume.analysis.requested",
            "application": get(uow, "event.application"),
        },
    })
)

This rule doesn't analyze the resume. It only decides that the analysis
should happen. The result isn't a textual response. It's a new event:

{
  "id": "0.request-resume-analysis",
  "type": "resume.analysis.requested",
  "timestamp": 1718050000000,
  "partition_key": "application-789",
  "application": {
    "id": "application-789",
    "status": "submitted",
    "resume_s3_key": "resumes/johndoe.pdf",
    "candidate": {"id": "candidate-123"},
    "job": {"id": "job-456"}
  },
  "triggers": [{
    "id": "candidate-applied-001",
    "type": "candidate.applied",
    "timestamp": 1718050000000
  }]
}

That event can be published to EventBridge and consumed by another
Lambda.

Up to this point, we haven't used an LLM at all. And that's deliberate.

Many agent decisions don't require generative AI. They require clear
rules, correct data, and well-modeled events.

The LLM as a Task

Now the LLM appears---but it appears late.

Before the prompt, we already had:

a business event;
persistence in the micro event store;
correlation;
an evaluation rule;
an event requesting analysis.

The LLM enters as a bounded task: analyzing the resume against the job
opening. For practical purposes, here's an implementation using OpenAI
Agents SDK:

from agents import Agent, Runner
from modmex import BaseModel
from modmex_lambda.stream.sources.sqs import sqs_source
from modmex_lambda.stream.flavors.task import Task

class ResumeAnalysis(BaseModel):
    matched_skills: list[str]
    missing_skills: list[str]
    confidence: float
    summary: str

resume_analyzer_agent = Agent(
    name="Resume analyzer",
    instructions=(
        "Analyze a resume against a job opening. "
        "Return a structured, auditable, and conservative evaluation. "
        "Do not invent skills that are not supported by the available evidence. "
        "confidence must be a number between 0 and 1."
    ),
    output_type=ResumeAnalysis,
)

class ResumeTextExtractor:
    def extract(self, resume_s3_key: str) -> str:
        # Real implementation:
        # 1. download the file from S3;
        # 2. extract text from the PDF/DOCX;
        # 3. clean or truncate the content if necessary.
        return "Extracted resume text..."

def analyze_resume_with_llm(uow, task):
    application = get(uow, "event.application")
    candidate = get(application, "candidate")
    job = get(application, "job")
    extractor = task.resolve(ResumeTextExtractor)
    resume_text = extractor.extract(application["resume_s3_key"])

    result = Runner.run_sync(
        resume_analyzer_agent,
        f"""
        Evaluate whether the candidate meets the job requirements.

        Candidate:
        {candidate}

        Job:
        {job}

        Resume:
        {resume_text}
        """,
    )

    analysis = result.final_output.model_dump()
    return {
        "candidate_id": candidate["id"],
        "job_id": job["id"],
        "application_id": application["id"],
        **analysis,
    }

listener_registry = RulesRegistry().registry(
    Task({
        "id": "analyze-resume",
        "event_type": "resume.analysis.requested",
        "execute": analyze_resume_with_llm,
        "emit": lambda uow, task, template: {
            **template,
            "type": "resume.analyzed",
            "application": {
                **get(uow, "event.application"),
                "analysis": uow["result"],
            },
        },
    })
)

@sqs_source(listener_registry, concurrency=True)
def handler(event, context):
    return {"statusCode": 200}

The LLM didn't decide to hire anyone. It produced a structured signal:

{
  "type": "resume.analyzed",
  "application": {
    "id": "application-789",
    "analysis": {
      "matched_skills": ["python", "aws", "serverless"],
      "missing_skills": [],
      "confidence": 0.87,
      "summary": "The candidate meets the primary requirements."
    }
  }
}

That signal returns to the flow as an event.

The important output isn't a polished response for a user. It's a new
fact that other components can evaluate, audit, and process.

The LLM produces signals. The control service decides what to do with
them.

Evaluate with context

When resume.analyzed arrives, the system returns to the control loop.

def qualifies_for_screening(uow):
    analysis = get(uow, "event.application.analysis", {})
    correlated = uow["correlated"]

    has_application = any(
        event["type"] == "candidate.applied"
        for event in correlated
    )

    return (
        has_application
        and analysis.get("confidence", 0) >= 0.80
        and len(analysis.get("missing_skills", [])) == 0
    )

trigger_registry.registry(
    Evaluate({
        "id": "qualify-candidate",
        "event_type": "resume.analyzed",
        "correlation_key_suffix": "application",
        "expression": qualifies_for_screening,
        "emit": lambda uow, rule, template: {
            **template,
            "type": "candidate.qualified",
            "application": {
                **get(uow, "event.application"),
                "status": "qualified",
                "recommendation": "screening",
            },
        },
    })
)

Here, Evaluate queries DynamoDB using the correlation key and receives
related events in uow["correlated"].

The agent's memory isn't a long conversation. It's a chain of durable
events.

If the rule passes, another event is emitted:

candidate.qualified

And that event can activate another decision:

trigger_registry.registry(
    Evaluate({
        "id": "request-interview",
        "event_type": "candidate.qualified",
        "emit": lambda uow, rule, template: {
            **template,
            "type": "interview.requested",
            "application": {
                **get(uow, "event.application"),
                "next_step": "interview",
            },
        },
    })
)

The complete flow becomes:

candidate.applied
        ↓
resume.analysis.requested
        ↓
resume.analyzed
        ↓
candidate.qualified
        ↓
interview.requested

This looks much more like a real agent---not because it has a longer
prompt, but because it observes, remembers, evaluates, and acts.

Where exactly does the LLM fit?

It's worth repeating because this is the most important point:

The LLM doesn't listen to events.
The LLM doesn't coordinate the process.
The LLM isn't the memory system.
The LLM doesn't decide everything.
The LLM participates when a rule needs probabilistic evaluation.

The right mental model is:

Event:
  candidate.applied

Control service:
  collect
  correlate
  evaluate

Decision:
  we need to analyze the resume

Event:
  resume.analysis.requested

Task:
  call LLM

Event:
  resume.analyzed

Control service:
  evaluate with context

Event:
  candidate.qualified

The prompt appears late. An event happened first.

Expire: time without live processes

There's another important detail in real systems: time.

Many decisions depend not only on something happening, but on something
not happening within a certain period.

For example:

InterviewRequested
        ↓ 48 hours without a response
InterviewRequestExpired
        ↓
HumanReviewRequired

In a traditional design, we might create a permanent worker, a
scheduler, or a table of pending jobs. In this serverless
implementation, we can use DynamoDB TTL and turn expirations into events
through Expired.

This lets us express temporal logic without keeping a live process
constantly checking state.

Again, the agent doesn't need to be "thinking." It needs to react when
the system observes a new fact---even when that fact is that a time
window expired.

Why not let the LLM orchestrate everything?

At this point, a reasonable question appears: if today's models can call
tools natively, why build all this infrastructure with Lambdas, queues,
and databases? Why not connect an LLM to a set of tools, give it
context, and let it orchestrate the flow autonomously?

It's a valid question.

But the answer is fundamental to designing production agents:

An LLM is an excellent probabilistic reasoning engine, but a poor
infrastructure controller.

Delegating the primary orchestrator to an LLM creates serious problems:

Determinism vs. probability. Critical business routing cannot depend on a model's temperature. If a strict rule says the flow must stop when a required document is missing, you need deterministic code. Rules evaluate precisely; LLMs predict the next token.
Durable memory vs. context window. Traditional agents often try to preserve memory by injecting execution history into the prompt. If a process lasts days or accumulates dozens of events, context grows, latency increases, costs rise, and attention degrades. Operational memory belongs in a database, not a token window.
Fault tolerance. What happens when an external API times out? In an event-driven architecture, a failed task can be retried from the queue or moved to a Dead Letter Queue (DLQ). The whole system doesn't need to collapse.
Real asynchrony. Business decisions take time. If we need to wait 48 hours for a candidate's response, an LLM cannot remain in an infinite loop waiting. An asynchronous design with expirable events handles time naturally without idle processes.

The LLM doesn't disappear from this architecture. It simply occupies the
place where it provides the most value.

The control service coordinates the flow.
Events preserve state.
Infrastructure provides resilience.
The LLM participates when we need interpretation, classification, summarization, or probabilistic judgment.

Each component does what it was designed to do.

Why does serverless fit so well?

Serverless fits event-driven agents for a simple reason:

An event-driven agent spends most of its time waiting.

You don't need to pay for an idle process just so the agent can exist.
You need the system to wake up correctly when something relevant
happens.

Pay per use

If there are no applications, analyses, interviews, or feedback, there
are no invocations.

no events = no invocations = near-zero compute cost

This matters even more when LLMs are involved because we don't only want
to control compute cost. We also want to control when and why inference
cost is incurred.

Automatic scalability

If 10 applications arrive, you process 10.

If 10,000 arrive, Lambda scales with the event volume while SQS,
Kinesis, or DynamoDB Streams absorb the spike.

The architecture doesn't need to assume a fixed number of running
agents. Throughput follows the event flow.

Failure isolation

Separating actions through events gives each capability its own
boundary:

resume analysis;
correlation;
decision;
notification;
interview scheduling;
human review.

If the LLM fails, the whole agent doesn't have to fail. The failure can
be recorded as an event. It can be retried. It can be escalated. It can
be sent to human review.

Auditability

Every important decision produces an event:

resume.analysis.requested
resume.analyzed
candidate.qualified
interview.requested

This lets us reconstruct why the system acted.

In systems that use LLMs, that traceability matters. It isn't enough to
know that "the model said something." We need to know which event
triggered it, what data was available, which rule ran, and which action
was emitted.

Evolution

Adding a new capability doesn't require rewriting the entire agent.

You can add another rule:

RulesRegistry().registry(
    Evaluate({...}),
    Task({...}),
)

Or add a new EventBridge consumer.

This lets the system evolve by adding capabilities rather than through
massive rewrites.

The complete agent

When we put the pieces together, the resulting system doesn't look like
a chatbot.

It also doesn't look like a linear workflow of prompts.

It is implemented using control-system patterns.

It observes lower-level events. It stores them. It correlates them. It
evaluates conditions. It emits higher-level events. It executes actions.
And those actions produce new events.

That loop is a practical way to implement the agent.

Conclusion

I think much of the current confusion around agents comes from starting
the conversation with the prompt. The important shift isn't only
technical. It's a change in mental model.

If we start with the prompt, we end up designing conversations.

If we start with the event, we can design control systems.

Prompts matter. LLMs matter too. But before a prompt exists, something
has usually already happened.

A candidate applied.
A customer wrote.
A document was uploaded.
A payment was approved.

A production agent needs to react to those facts. It needs durable
memory. It needs correlation. It needs rules. It needs auditability. And
at some points, it may need an LLM.

But the LLM doesn't define the agent.

In this architecture, the agent is implemented as a control loop:

event
  ↓
collect
  ↓
correlate
  ↓
evaluate
  ↓
emit
  ↓
action
  ↓
event

Agents don't start with prompts. In production, they start with
events.

Agents Don't Start with Prompts. They Start with Events.

Alejandro Hernández — Thu, 13 Aug 2026 04:02:09 +0000

Lately, it seems like everything is an agent. Open LinkedIn and you'll
find posts about AI Agents. Go to YouTube and you'll see tutorials on
LangChain, OpenAI Agents, CrewAI, AutoGen, and a long list of frameworks
promising to build autonomous agents capable of performing complex
tasks.

After consuming enough of this content, it's easy to conclude that an
agent is simply an LLM connected to a set of tools. From my perspective,
that's the wrong way to think about it.

Most diagrams look something like this:

Prompt
  ↓
LLM
  ↓
Tool
  ↓
LLM
  ↓
Response

There's nothing inherently wrong with this model. In fact, it's
extremely useful for solving a wide range of problems. The problem
begins when we confuse one implementation pattern with the complete
definition of an agent.

To understand why, let's think about something millions of people do
every day: hiring.

When someone applies for a job, an important fact has occurred. Someone
submitted an application, and the recruiting process has begun. From
that moment on, many things can happen: the resume is analyzed, an
interview is scheduled, feedback is collected, experience is validated,
an offer is approved, and eventually a decision is made.

If we represented that process as events, it might look something like
this:

CandidateApplied
        ↓
ResumeAnalyzed
        ↓
InterviewScheduled
        ↓
InterviewCompleted
        ↓
FeedbackReceived
        ↓
OfferSent

Now let's ask an interesting question: where is the agent?

Under the current popular paradigm, we might say the agent is the model
that analyzed the resume. But that explanation is incomplete. Resume
analysis represents only a small part of the overall process. The
complete system observed new information, evaluated the current
situation, and executed actions to move the process forward.

In other words, the agent didn't appear when someone wrote a prompt.
The agent started acting when an event occurred.

This distinction may seem subtle, but it completely changes how we
design systems.

A recruiter doesn't wake up in the morning waiting for prompts. They
receive events. A candidate applies for a job. An interviewer submits
feedback. A manager approves a hire. A candidate rejects an offer. Each
new fact changes the state of the process and creates the need for new
decisions.

The same thing happens in almost every organization. A customer sends an
email. A payment is approved. A shipment changes status. A document is
uploaded. A support ticket is created.

The real world is made of events, not prompts.

Of course, an AI model may become involved at some point. It might
analyze a resume, classify an email, summarize a document, or determine
a customer's intent. It might even be an LLM. But regardless of the
technology being used, the agent is still the complete system. The model
participates in a decision; it doesn't define the agent by itself.

Imagine, for example, that a model analyzes a resume and determines that
the candidate meets the minimum requirements for the position. The
important output isn't the textual response generated by the model. The
important output is the new fact that was discovered:

ResumeAnalyzed
CandidateQualified

From that point, the system can continue operating. It can schedule an
interview, request additional information, or notify the recruiter. The
model participated in a decision, but the overall flow remains
event-driven.

And this is where I think a more useful definition of an agent begins to
emerge.

If we look at the complete process, the agent isn't constantly producing
responses. It's observing facts, evaluating information, and generating
new facts that allow the process to continue moving forward.

A candidate applies for a job.
That produces new information.
That information is evaluated.
The evaluation produces a new fact: the candidate qualifies for the position.
That new fact triggers new decisions.
An interview is scheduled.
Feedback is collected.
An offer is recommended.

Each decision generates new facts that feed the next step in the
process.

From this perspective, an agent stops looking like a conversation with
tools and starts looking like an event-driven decision-making
system.

Those decisions can be made using business rules, machine learning
models, LLMs, or a combination of them. The important thing isn't the
technology used to make the decision. The important thing is that there
is a system capable of observing what happens, evaluating the available
information, and reacting accordingly.

I think this is where the current conversation about agents becomes
confusing. We've spent enormous amounts of time talking about prompts,
tool calling, context windows, and reasoning, but relatively little time
talking about what causes an agent to act in the first place.

Because before a prompt exists, something has usually already happened:

A customer sent a message.
A document was uploaded.
A payment was approved.
An order was created.

The event is the trigger. The prompt, when one exists, is simply a
tool used during the evaluation process.

That's why I'm increasingly convinced that we've started this
conversation from the wrong end. Agents are much more than prompt
workflows connected to tools. They are systems that observe events, make
decisions, and execute actions.

Some of those decisions may be made by business rules. Others by machine
learning models. Others by LLMs. What matters is that the agent isn't
defined by the technology used to make a decision, but by its ability to
react to what happens.

Maybe we're not just beginning to build agents. Maybe we've been
building them for years, and we've simply added new tools that help them
make better decisions.

Prompts matter. LLMs matter too. But neither answers the fundamental
question:

What caused the agent to act?

Most of the time, the answer isn't a prompt. It's an event.

Agents don't start with prompts. They start with events.

Building Lightweight and Streamable MCP Servers on AWS Lambda with Python

Alejandro Hernández — Wed, 12 Aug 2026 23:53:24 +0000

MCP servers don't always need containers, persistent processes, or a full web framework.

For many tools, a regular Python AWS Lambda is enough:

MCP request
    ↓
API Gateway
    ↓
Lambda
    ↓
Python tool
    ↓
JSON-RPC response

But some operations are different.

A tool may spend 30 seconds searching, analyzing, or coordinating work and need to report progress while it runs.

For those workloads we need real Streamable HTTP:

tools/call
    ↓
progress
    ↓
progress
    ↓
progress
    ↓
final result

We wanted both models in Python without requiring applications to adopt different MCP programming models.

That led to two open-source projects:

modmex-lambda — the Python MCP runtime and programming model.
serverless-python-mcp — the Serverless Framework deployment integration.

Together they let a Python application start with a lightweight buffered MCP server and opt into real Lambda response streaming when the workload actually needs it.

Start with a regular Python Lambda

The simplest deployment doesn't require Lambda Web Adapter or response streaming.

Install modmex-lambda:

pip install modmex-lambda

Create an MCP server:

from modmex_lambda import APIGatewayHttpResolver
from modmex_lambda.mcp import MCPServer

mcp = MCPServer(
    name="orders",
    version="1.0.0",
)

Then expose capabilities as regular Python functions.

Tools

@mcp.tool()
def get_order(order_id: str) -> dict:
    return {
        "id": order_id,
        "status": "confirmed",
    }

Resources

@mcp.resource("orders://{order_id}")
def order_resource(order_id: str) -> dict:
    return load_order(order_id)

Prompts

@mcp.prompt()
def order_assistant(customer_id: str):
    return build_order_prompt(customer_id)

Mount the MCP server on the normal API Gateway resolver:

app = APIGatewayHttpResolver()

app.include_mcp(
    mcp,
    path="/mcp",
)

handler = app.handler

The resulting architecture is deliberately boring:

MCP Client
    ↓
API Gateway HTTP API v2
    ↓
AWS Lambda
    ↓
modmex-lambda
    ↓
MCPServer

For short-lived tools, resources, and prompts, that's usually exactly what we want.

No FastAPI.

No Flask.

No ASGI server.

No response-streaming infrastructure.

Just Python and Lambda.

MCP is another interface to the application layer

One of the design goals was not to create a separate application architecture for MCP.

Tools can use the same dependency injection mechanisms as regular Lambda endpoints:

@mcp.tool()
def get_order(
    order_id: str,
    service: Annotation[OrderService, Depends()],
):
    return service.get(order_id)

That means REST and MCP can remain thin interfaces over the same application services:

                 OrderService
                     ▲
                     │
          ┌──────────┴──────────┐
          │                     │
       REST API                MCP

The same idea applies to middleware.

Authorization, tenant resolution, logging, auditing, tracing, and policies don't need to be implemented inside every tool:

@mcp.tool(
    middlewares=[
        RequirePermission("orders:read"),
    ]
)
def get_order(...):
    ...

MCP becomes another transport into the application rather than another application architecture.

Why buffered MCP is useful

It's easy to associate MCP with streaming, but many MCP operations don't benefit from it.

Consider:

get_customer
get_order
calculate_route
lookup_inventory
read_resource
get_prompt

If a tool finishes in 300 milliseconds or two seconds, a normal Lambda response is simpler.

For this reason, streaming isn't a requirement in modmex-lambda.

You can run MCP through a regular managed Python Lambda and API Gateway HTTP API v2.

That gives us the first deployment model:

Python
+
modmex-lambda
+
Lambda
+
HTTP API v2

Then, when a workload actually needs incremental communication, we can move to the second model.

When buffered responses stop being enough

Consider a tool that performs several expensive steps:

@mcp.tool()
def analyze_market(ctx: MCPContext):
    opportunities = search_opportunities()
    ranked = rank_opportunities(opportunities)
    analysis = analyze_market_conditions(ranked)

    return build_recommendation(analysis)

Maybe the complete operation takes 30 or 40 seconds.

With a buffered response, the MCP client sees nothing until the function finishes.

Instead, we want the tool to report progress:

@mcp.tool()
def analyze_market(ctx: MCPContext):

    ctx.progress.report(
        1,
        total=4,
        message="Searching opportunities",
    )

    opportunities = search_opportunities()

    ctx.progress.report(
        2,
        total=4,
        message="Ranking candidates",
    )

    ranked = rank_opportunities(opportunities)

    ctx.progress.report(
        3,
        total=4,
        message="Analyzing market conditions",
    )

    analysis = analyze_market_conditions(ranked)

    ctx.progress.report(
        4,
        total=4,
        message="Building recommendation",
    )

    return build_recommendation(analysis)

Those progress reports are translated into MCP notifications/progress messages and sent over the same Streamable HTTP response before the final JSON-RPC result.

Now we need real response streaming.

Real MCP streaming from Python Lambda

For streaming, modmex-lambda provides LambdaWebAdapterResolver.

The application remains Python:

from modmex_lambda import LambdaWebAdapterResolver
from modmex_lambda.mcp import MCPServer

mcp = MCPServer(
    name="orders",
    version="1.0.0",
)

app = LambdaWebAdapterResolver()

app.include_mcp(
    mcp,
    path="/mcp",
)

handler = app.handler

The infrastructure changes underneath it:

MCP Client
    ↓
API Gateway REST API
    ↓
responseTransferMode = STREAM
    ↓
AWS Lambda
    ↓
Lambda Web Adapter
    ↓
Python application
    ↓
modmex-lambda

Lambda Web Adapter connects the HTTP response produced by the Python application with Lambda response streaming.

Now an MCP tool can emit progress while it is still running:

0s    tools/call
      ↓
4s    notifications/progress
      "Searching opportunities"
      ↓
12s   notifications/progress
      "Ranking candidates"
      ↓
21s   notifications/progress
      "Analyzing market conditions"
      ↓
30s   final JSON-RPC result

The Lambda invocation hasn't completed when those progress messages reach the MCP client.

That's real incremental MCP streaming.

Deployment is the second half of the problem

Getting streaming to work inside Python is only part of the job.

A streaming Lambda deployment also needs the right infrastructure:

Lambda Web Adapter
response streaming mode
API Gateway REST API
STREAM transfer mode
launcher configuration
architecture-specific adapter layer
packaging

We didn't want every Python MCP service to reproduce that configuration manually.

That's why we built serverless-python-mcp.

Install it:

npm install --save-dev serverless-python-mcp

and register it like any other Serverless Framework plugin:

plugins:
  - serverless-python-mcp

MCP servers are declared under custom.pythonMcp.servers.

Lightweight deployment with HTTP API v2

For a normal buffered MCP server:

custom:
  pythonMcp:
    servers:
      orders:
        handler: app.handler
        transport: httpApi
        streaming: false

The application uses:

app = APIGatewayHttpResolver()
app.include_mcp(mcp, path="/mcp")

handler = app.handler

The plugin creates a normal Lambda behind API Gateway HTTP API v2.

No Lambda Web Adapter is added.

No streaming launcher is added.

This remains the lightweight deployment path.

Streamable deployment with REST API

When the same class of application needs real streaming:

custom:
  pythonMcp:
    servers:
      orders:
        handler: app.handler
        transport: http
        streaming: true

The Python application switches to:

app = LambdaWebAdapterResolver()
app.include_mcp(mcp, path="/mcp")

handler = app.handler

The plugin takes care of the AWS-specific pieces required for streaming.

It attaches the architecture-specific Lambda Web Adapter layer, configures the execution wrapper and streaming mode, creates the launcher used by the HTTP process, and configures the REST API integration for streaming.

The developer still works with a Python MCP server.

Three deployment front doors

serverless-python-mcp currently supports three AWS front doors:

Transport	AWS front door	Buffered	Streaming
`httpApi`	API Gateway HTTP API v2	Yes	No
`http`	API Gateway REST API v1	Yes	Yes
`url`	Lambda Function URL	Yes	Yes

This lets the infrastructure match the workload.

For a simple internal MCP service:

transport: httpApi
streaming: false

For an MCP server that needs API Gateway capabilities and real streaming:

transport: http
streaming: true

And for cases where a Function URL is sufficient:

transport: url
streaming: true

The application doesn't need a new MCP abstraction for each one.

REST API without streaming is supported too

Streaming and transport are intentionally separate choices.

For example:

custom:
  pythonMcp:
    servers:
      orders:
        handler: app.handler
        transport: http
        streaming: false

uses API Gateway REST API but invokes the Python Lambda normally.

The application uses:

app = APIGatewayRestResolver()

This can be useful when REST API features are desired but incremental MCP streaming isn't.

The deployment model therefore isn't simply:

HTTP API = simple
REST API = streaming

It's more accurately:

                       Buffered       Streaming

HTTP API v2               ✓               -

REST API v1               ✓               ✓

Function URL              ✓               ✓

Paths and multiple MCP servers

Each server can expose its own path:

custom:
  pythonMcp:
    servers:
      orders:
        handler: orders.handler
        transport: http
        streaming: true
        path: /orders/mcp

      inventory:
        handler: inventory.handler
        transport: http
        streaming: true
        path: /inventory/mcp

The Python application registers the same path:

app.include_mcp(
    mcp,
    path="/orders/mcp",
)

Servers using API Gateway can share the underlying API while keeping separate Lambda functions and MCP endpoints.

That makes it possible to expose multiple domain capabilities without building one giant MCP server.

Authentication remains infrastructure

The plugin also deliberately doesn't invent an MCP-specific authentication model.

For HTTP API, existing Serverless authorizer configuration can be used.

For REST API, the plugin passes authorizer configuration through to the normal Serverless REST API event compiler.

Function URLs can use their supported public or AWS IAM modes.

So the architecture remains:

MCP Client
    ↓
AWS authentication / authorizer
    ↓
MCP transport
    ↓
middleware / application authorization
    ↓
tool

This keeps authentication independent from the MCP programming model.

Streaming should be earned

An important lesson from building this was that streaming shouldn't become the default architecture just because MCP supports it.

For many servers:

HTTP API v2
+
Lambda
+
modmex-lambda

is enough.

It's lightweight and fits the serverless execution model extremely well.

Streaming becomes useful when the operation actually has intermediate information worth delivering.

Then we can move to:

REST API
+
Lambda response streaming
+
Lambda Web Adapter
+
modmex-lambda

without redesigning tools, resources, prompts, middleware, or application services.

A note about cancellation

There is one serverless behavior worth understanding.

A client disconnect doesn't guarantee that the Lambda invocation immediately stops.

There are multiple network boundaries between the MCP client and the Python process:

MCP Client
    ↓
API Gateway
    ↓
Lambda
    ↓
Lambda Web Adapter
    ↓
Python

When the transport can observe a disconnect, modmex-lambda can propagate cooperative cancellation through MCPContext.

A long-running tool can therefore check:

if ctx.cancelled:
    return {"status": "cancelled"}

But applications shouldn't assume that every downstream network failure will immediately terminate a running Lambda invocation.

Response streaming and distributed execution cancellation are separate concerns.

One programming model, different infrastructure

The final architecture looks like this:

                         MCPServer
                            │
             ┌──────────────┴──────────────┐
             │                             │
             ▼                             ▼
      Buffered execution             Streamable execution
             │                             │
      regular Lambda                  HTTP process
             │                             │
             ▼                             ▼
   HTTP API / REST / URL            Lambda Web Adapter
                                           │
                                           ▼
                                    Lambda streaming

The important part is what doesn't change:

tools
resources
prompts
dependency injection
middleware
application services

Streaming is an infrastructure capability, not a new application architecture.

Open source

The complete implementation is available in two projects:

modmex-lambda contains the Python MCP runtime and application integration.

It provides the MCP server, tools, resources, prompts, middleware, dependency injection, protocol validation, buffered HTTP transports, and Streamable HTTP support.

serverless-python-mcp provides the Serverless Framework deployment integration.

It creates MCP Lambda functions from custom.pythonMcp.servers and configures the appropriate AWS front door and runtime behavior for buffered or streaming execution.

The design goal behind both projects is straightforward:

You don't need streaming to run MCP on Lambda. But when you need it, you shouldn't have to rewrite your MCP server.

Start with the smallest architecture that works.

Add streaming when the workload earns the complexity.

Keep the Python application the same.