Overview
The design is practical and validated on AWS with concrete savings; evidence is empirical but limited to two apps, specific MCP tools, and GPT-4o-mini, so expect implementation and workload-specific variance.
Citations0
Evidence Strength0.78
Confidence0.85
Risk Signals11
Trust Signals
Findings with numeric evidence: 5/5
Findings with evidence refs: 5/5
Results with explicit delta: 5/5
Reproducibility
Status: Partial assets available
Open source: Unknown
At A Glance
Cost impact: 80%
Production readiness: 70%
Novelty: 50%
Why It Matters For Business
You can host multi-step, tool-using LLM agents on serverless platforms to cut latency, token bills, and operational overhead—if you add durable memory, S3 caching, and carefully deploy MCP tools.
Who Should Care
Summary TLDR
FAME is a serverless architecture that runs multi-agent LLM workflows (ReAct pattern) as AWS Lambda functions orchestrated with Step Functions. It stores agent state in DynamoDB, wraps MCP tool servers as Lambda functions, caches deterministic tool outputs in S3, and supports function fusion. On two apps (paper summarization, log analytics) FAME achieves up to 13× lower latency, up to 88% fewer input tokens, and up to 66% lower monetary cost versus stateless baselines, while improving completion rates. Results come with caveats: tested on AWS, GPT-4o-mini, and a limited workload set.
Problem Statement
Hosting multi-step, tool-using agentic workflows on VMs is costly and hard to scale. FaaS gives autoscaling and billing per request but is stateless, which breaks multi-turn agent memory and increases redundant LLM calls and tool invocations. MCP tool servers also need special deployment and can cause cold-start and billing overheads when naively hosted.
Main Contribution
FAME: a FaaS architecture that decomposes ReAct agents into Planner, Actor, Evaluator Lambda functions orchestrated with AWS Step Functions.
Automated, durable agent memory injection using DynamoDB plus an automated wrapper to deploy FastMCP servers as Lambda functions.
Key Findings
Combined agent memory plus MCP caching reduced end-to-end latency by up to 13×
Input tokens to the LLM dropped by as much as 88%
Results
| Metric | Value | Baseline | Delta | Split / Dataset | Evidence | Evidence Ref |
|---|---|---|---|---|---|---|
| End-to-end latency | up to 13× reduction | Empty/naive memory configs | ≤13× speedup (M+C vs E/N) | Research Summarization and Log Analytics (§5.2.1 Fig.4) | M+C config achieved up to 13× faster E2E completion vs baselines | §5.2.1 Fig.4 |
| LLM input tokens | up to 88% reduction | Empty/naive memory configs | ≈88% fewer input tokens (e.g., 35,646→4,536) | Research Summarization P1 (§5.2.2 Fig.5) | Agent memory and MCP caching avoided re-ingesting full documents | §5.2.2 Fig.5 |
What To Try In 7 Days
Break a ReAct agent into Planner/Actor/Evaluator as separate functions and orchestrate with Step Functions.
Persist session agent state in DynamoDB and inject it into Planner prompts for multi-turn continuity.
Wrap deterministic MCP tools to return S3 handles and enable TTL-based caching to reduce token and latency costs.
Agent Features
Memory
Planning
Tool Use
Frameworks
Is Agentic
Yes
Architectures
Collaboration
Optimization Features
Token Efficiency
Infra Optimization
System Optimization
Inference Optimization
Reproducibility
Data URLs
Risks & Boundaries
Limitations
Experiments limited to two reference apps and a small set of MCP tools.
Evaluation done on AWS Lambda/Step Functions and GPT-4o-mini—results may differ on other clouds or LLMs.
When Not To Use
Workloads with long-running tools that exceed FaaS timeouts without async patterns.
Very high-throughput, GPU-bound inference where specialized inference infra is required.
Failure Modes
LLM ignores injected memory and reissues redundant tool calls.
Misconfigured cache TTL returns stale or incorrect tool outputs.