Overview
Production Readiness
0.8
Novelty Score
0.6
Cost Impact Score
0.7
Citation Count
1
Why It Matters For Business
P‑t‑E gives auditable, predictable automation and architectural defenses against prompt injection, lowering risk for regulated or high‑value workflows.
Summary TLDR
This paper argues that splitting agent behavior into a Planner (one strong LLM) and an Executor (simpler component) yields more predictable, cost‑efficient, and secure LLM agents than reactive loops. It gives a security-first blueprint: lock the plan before running tools, scope tool access per task, sandbox code execution (Docker), and add verifier/HITL and re-planning loops. The guide includes runnable examples and framework-specific recipes for LangGraph, CrewAI, and AutoGen. Use P-t-E for multi-step, auditable workflows; beware upfront token/latency costs and add layered controls.
Problem Statement
LLM agents that call tools can be powerful but are vulnerable, unpredictable, and costly when implemented as stepwise reactive loops. The paper asks: how do architects build agentic systems that are predictable, cost‑effective, and resistant to prompt‑injection and unsafe tool use?
Main Contribution
Clear exposition of the Plan‑then‑Execute (P‑t‑E) pattern: planner vs executor vs optional verifier/refiner
Security blueprint: control-flow integrity, least privilege tool scoping, input/output sanitization, Docker sandboxing, and HITL/Plan‑Validate‑Execute
Concrete, runnable implementation guides and code examples for LangGraph (stateful graphs), CrewAI (task-scoped tool access), and AutoGen (Dockerized execution)
Advanced patterns: re-planning loops, DAG-based parallel execution (up to 3.6x), GraphQL for token efficiency, and hierarchical/sub-planner designs
Key Findings
Plan‑then‑Execute locks control flow before ingesting untrusted tool outputs, reducing risk of indirect prompt injection.
P‑t‑E front-loads LLM reasoning to one or few planner calls instead of one LLM call per action.
Parallelizing independent plan steps as a Directed Acyclic Graph produced up to a 3.6× speedup on I/O‑bound workloads in cited evaluations.
Comprehensive planning calls can consume large token budgets in one shot.
Results
Parallel execution speedup
Planner token consumption
Who Should Care
What To Try In 7 Days
Prototype a Planner + simple Executor for a 3‑step internal workflow to measure token and latency trade-offs
Add task-level tool scoping to an existing multi-tool agent to test least‑privilege enforcement
Enable Dockerized sandboxing for any code-executing agents and run a controlled exploit test on a dev sandbox
Agent Features
Memory
- Persistent state object with past_steps history
- TypedDict/StateGraph passed between nodes
Planning
- Single-shot Planner with structured output
- Re-planning loops
- DAG-based parallel planning
- Hierarchical/sub-planner decomposition
Tool Use
- Task-scoped tool provisioning
- RBAC-style role mapping
- GraphQL queries as compact tools
Frameworks
- LangChain
- LangGraph
- CrewAI
- AutoGen
Is Agentic
true
Architectures
- Planner-Executor
- Hierarchical (manager-worker)
- Stateful Graph (LangGraph)
Collaboration
- Manager-worker delegation (CrewAI)
- Group chat orchestration with speaker selection (AutoGen)
Optimization Features
Token Efficiency
- GraphQL to reduce returned fields and tokens
- Sub-planners to lower single-call token budgets
Infra Optimization
- Docker sandboxing for code execution
- Tiered sandboxing based on task role
System Optimization
- DAG-based parallel execution
- Executor use of smaller models or deterministic functions
Reproducibility
Code Available
Open Source Status
- partial
Risks & Boundaries
Limitations
- High upfront latency and token cost for the Planner phase
- A flawed plan remains dangerous—Plan validation is required for high-risk tasks
- P‑t‑E adds engineering complexity (re-planning, DAG scheduling, role mapping)
When Not To Use
- Single-step, low-latency queries where time-to-first-action matters
- Simple chatbots or one-off Q&A where ReAct is cheaper and faster
Failure Modes
- Convincingly wrong plan approved and executed (human oversight applied too late)
- Malicious tool output contaminates data passed between steps, causing downstream harm
- Wasted tokens/time when a costly upfront plan must be discarded without re-planning
Core Entities
Models
- GPT-4
- Claude 3 Opus
- gpt-4o
Metrics
- execution latency
- token consumption
- parallel speedup
Context Entities
Models
- gpt-4o-mini