Agentic Patterns: From Simple Prompts to Swarm Intelligence

You built the demo. It worked beautifully in the pitch.

Then you shipped it — and three weeks later you were debugging why the agent was confidently doing the wrong thing at 2 am. Sound familiar?

Here’s the thing most teams discover too late: building an LLM-powered feature isn’t the hard part. Building one that holds up in production is. And the difference almost always comes down to not having the right vocabulary — treating every agent as a “chatbot with tools” instead of reasoning about the structural patterns underneath.

This series is about those patterns.

Who This Series Is For

We’re writing this for builders who’ve already moved past “hello world” with LLMs:

• Senior engineers and architects designing AI-assisted systems
• Product and platform teams running agentic AI experiments in production
• Builders who know how to call an LLM API and now want systems that don't collapse on day 3

We’ll assume you’re comfortable reading pseudo-code, reasoning about architecture diagrams, and thinking in terms of reliability, latency, and cost. We won’t slow down to explain what an API is.

What We Mean by “Agentic Patterns”

An agentic pattern is a reusable way of structuring how an LLM-based system reasons, acts, and coordinates — with tools, with humans, and with other agents.

Patterns are not frameworks. Every example in this series is implemented in plain Python — no third-party orchestration libraries, no magic. The goal is that you understand the mechanic so thoroughly that you could implement it in any language, with any stack. Once the pattern is clear, the framework is just a delivery choice.

Once you understand the pattern, three things become possible:

• You recognise when you’re accidentally reinventing it — and stop wasting time.
• You reuse it deliberately across domains, teams, and projects.
• You compose multiple patterns into something that’s actually robust.

That composability is the whole point. A single pattern rarely solves a real problem on its own. The real power is knowing which two or three to combine — and which ones to leave out.

The Company We’ll Build With: ABCKart

Every pattern in this series is illustrated with a concrete, worked example from the same company. We use one company throughout so you’re not switching mental context every post — you’re watching a real system evolve.

ABCKart is a Bengaluru-based direct-to-consumer sports and outdoor brand. Founded in 2020, they sell under their own label — running gear, trekking equipment, fitness accessories, and sports apparel. By 2025 they’ve reached ₹12 Crore ARR, roughly 6,000 active SKUs, and sell across four channels: their own website (on Shopify), Amazon India, Flipkart, and Meesho.

They’re not a startup anymore, but they’re not a scaled enterprise either. They have the transaction volume to feel the pain of manual processes acutely, and the team size that makes hiring their way out of it expensive. India’s e-commerce landscape amplifies this: carrier fragmentation, high return rates, multi-marketplace complexity, and GST reconciliation across channels create integration headaches that most Western markets rarely face at this scale.

That combination — real volume, limited headcount, fragmented ecosystem — is exactly where agentic AI pays for itself fastest.

The Team

The Systems

ABCKart runs on a stack typical of Indian mid-market D2C brands — functional, but deeply fragmented:

• OMS — order status, fulfilment state, payment records; built on Unicommerce
• WMS — inventory levels at two fulfilment centres, dispatch logs, returns inward
• CRM — customer contact history, LTV segmentation, repeat-buyer flags; a mix of Zoho CRM and spreadsheets
• Carrier integrations — Delhivery, Bluedart, and Ecom Express with separate portals and inconsistent API coverage; ABCKart uses ClickPost as a partial aggregator but tracking data still lags by hours
• Marketplace seller panels — Amazon Seller Central, Flipkart Seller Hub, and Meesho Supplier Panel are entirely separate systems with separate reporting, separate return workflows, and different SLA clocks
• Payment reconciliation — Razorpay for the direct site, plus separate settlement reports from each marketplace; reconciling these weekly is a half-day manual task
• GST and compliance — returns, replacements, and B2B orders all generate separate GST treatments; handled in Tally with manual entries from operations
• Pricing database — internal price records, marketplace fee calculators, and competitor price snapshots maintained in a shared Google Sheet

Here’s the uncomfortable truth: these systems do not talk to each other. Not by accident — by design. Every carrier, marketplace, and financial platform has built its own walled garden. Every operational decision that crosses more than one system requires a human to open multiple tabs, export CSVs, paste into spreadsheets, and reconcile manually.

In India’s e-commerce market, that’s not a technical debt problem unique to ABCKart — it’s the default state for most brands at this scale. And it’s the root cause of almost every problem the patterns in this series will solve.

Eight platforms. The team member in the middle is the only integration layer — open tabs, CSV exports, manual reconciliation.

The Problems They Face

At ABCKart’s scale, the pain points are recognisable to anyone running a D2C brand in India:

• CS team handles 120–160 inbound messages per day across four channels. Around 55–60% are delivery and return queries that follow predictable patterns — but require data from at least two separate systems to answer correctly. Each takes 10–15 minutes manually.
• Buying team makes sourcing and reorder decisions with incomplete data. Pulling demand signals, current inventory, competitor pricing, and supplier lead times together takes longer than the decision window — so gut feel fills the gap.
• Ops team runs inventory and pricing reviews manually, weekly. Competitor prices on Flipkart and Amazon can change daily. A brand reacting on a weekly cadence is structurally late.
• Marketing team sends campaigns to 180,000 subscribers across email and WhatsApp. Compliance issues, technical errors, and quality problems are caught inconsistently — or not at all until after send.
• Commercial head makes strategic category decisions — which ranges to expand, which to exit, which vendors to consolidate — with analysis assembled over several days by hand. The window for good decisions is shorter than the time to prepare for them.

None of these are problems that traditional automation solves well. Rule-based systems break as soon as the real world deviates from the rule. Scripted integrations cover the happy path but collapse on the 20–25% of cases that have nuance — and in Indian e-commerce, the edge case rate is particularly high: partial shipments, marketplace-specific return windows, GST-exempt categories, COD orders with open payment status.

Hiring more people extends the runway. It doesn’t change the unit economics.

How ABCKart Evolves Across the Series

We start with the simplest possible agentic setup: one agent, one task, no tools. From there, each pattern adds exactly the capability the previous one was missing. By pattern 20, ABCKart has a composable agent library where specialist agents are packaged as callable tools and orchestrated by higher-level systems.

No post jumps ahead. Every capability introduced exists because the previous approach hit a specific, identifiable wall. That progression — and the wall at each step — is the real curriculum.

The 20 Patterns We’ll Cover

We’ll follow the journey most teams take in the real world: start brutally simple, add complexity only when the simpler version has failed you, and stop the moment it’s good enough.

Where each pattern sits on the complexity vs. business impact map — start in the top-left, grow right as your system matures.

1. Single-Agent Pattern — one LLM, one prompt, one response. The ground floor every other pattern builds on. We cover when to stay here — and the exact signals that tell you to move on.
2. Chain-of-Thought Pattern — structured step-by-step reasoning that fixes brittle multi-step logic and produces inspectable traces your team can actually debug.
3. Tool-Use Pattern — giving agents typed API contracts to call live data, databases, and side-effecting services. The first step from “just a brain” to an agent that touches the real world.
4. Parallel Pattern — fanning out independent tool or sub-agent calls for lower wall-clock latency. We cover dependency analysis, partial-failure handling, and aggregation strategies.
5. Iterative Refinement Pattern — improving outputs across multiple passes with a feedback signal. When one-shot answers aren’t good enough and you need convergence, not a guess.
6. Review & Critique Pattern — splitting producer and critic into distinct agents so quality checking is structurally separate from generation. Two-agent setup with worked examples.
7. Reflection Pattern — agents that inspect their own past outputs and self-correct without human prompting. Persistent reflection logs, failure classification, and re-planning.
8. Loop Pattern — simple goal-driven loops where the agent acts, checks a termination condition, and keeps going until the job is done or a limit is hit.
9. ReAct Pattern — interleaving Thought → Action → Observation cycles so every tool call is grounded in explicit reasoning. Includes the minimal protocol spec and stop-condition design.
10. Memory-Augmented Agent Pattern — equipping agents with short-term, long-term, and episodic memory so they reason coherently across multiple requests and sessions.
11. HITL Checkpoint Pattern — placing human approval exactly where risk crosses a threshold, automating everything else. Covers risk-tier routing, approval UX, and audit logging.
12. Hierarchical Task Decomposition Pattern — a planner that breaks complex goals into subtasks and delegates each to a worker. Goal graphs, dependency ordering, and re-planning on failure.
13. Coordinator Pattern — a lightweight router that classifies incoming work and dispatches it to the right specialist without doing the work itself. Intent classification and routing tables.
14. Orchestration & Routing Pattern — system-level graph control flow: conditional branches, join nodes, retry policies, and fallback paths across a multi-step agent pipeline.
15. Multi-Agent Collaboration Pattern — specialist agents with defined roles (researcher, planner, executor, reviewer) collaborating via shared state or a coordinator. Three collaboration structures covered.
16. Blackboard Pattern — a shared mutable workspace that all agents read and write to as a coordination surface. Conflict resolution, versioning, and when blackboard beats direct messaging.
17. Swarm Pattern — multiple agents or runs generate candidates in parallel; a judge selects or merges the best. Includes diversity sources, evaluation mechanisms, and aggregation strategies.
18. Tree-of-Thoughts Pattern — branching reasoning trees where each branch is a hypothesis and a search algorithm picks the best path. When linear CoT isn’t enough for complex decisions.
19. Graph-of-Thoughts Pattern — non-linear reasoning where ideas and evidence form nodes in a graph, not a single chain. For problems where conclusions genuinely depend on multiple parallel reasoning threads.
20. Agents-as-Tools Pattern — packaging mature agents behind typed callable interfaces so any workflow can invoke them like a library. Input/output contracts, versioning, and capability metadata.

You do not need all of these in every system. In fact, that’s one of the core lessons of this series: resist the pull toward complexity until the simpler version has failed you. Most production problems are solved somewhere between patterns 1 and 6.

What Every Post Includes

We’re not writing reference docs. Each post is designed to be read in a coffee break and applied the same afternoon.

Every pattern post follows the same structure:

• Problem framing — what breaks without this pattern, with a specific failure mode, not a vague warning
• Definition and mental model — the simplest possible way to think about it, usually in one paragraph
• When this helps — the conditions and signals that make this the right pattern to reach for, and when the simpler one is still enough
• Architecture sketch — core components, control flow, and data paths, shown visually
• Code snippets — plain Python showing the pattern's core loop with no framework dependencies, so you see exactly what's happening and can port it to any stack
• Concrete example — a worked scenario set at ABCKart, showing the pattern solving a real operational problem; each scenario connects directly to the previous one — when the last pattern hits a wall, the new pattern is the answer
• Design checklist — 4–6 questions to answer before you ship, designed to be copied directly into your design doc
• Pitfalls and anti-patterns — how this pattern fails in the wild, with specific mitigations
• Safety and guardrails — the constraints and failure-containment boundaries specific to this pattern, covering what to rate-limit, where approval is required, and what the agent must never do autonomously
• Observability and monitoring — the signals, metrics, and traces needed to run this pattern in production, with guidance on what to log, what to alert on, and how to diagnose failures
• Governance — who owns the agent, what process controls changes to its behaviour, and who is accountable when something goes wrong
• How this connects to the rest of the series — exactly which patterns from the series this one composes with and how
• GitHub companion code — a runnable implementation you can clone and adapt, hosted at github.com/flytebit/agentic-patterns

What the companion code covers — and what it doesn’t

Every post covers safety, observability, governance, and pitfalls in depth. The companion code does not implement any of these — each has its own ecosystem of tools and the right choice depends on your stack. The code does one thing: shows you how the pattern works, with every LLM call, tool invocation, and agent handoff visible and portable.

Read the post for design decisions. Run the code to understand the mechanics. Choose your own tools for the rest.

The design checklist is meant to be copied. Put it in your design doc, cross off what doesn’t apply, and keep what does. The GitHub companion code is there so you’re never starting from a blank file — fork it, adapt it, and ship it.

How to Read This Series

You can read straight through, from “LLM as a function call” to “composable agent libraries.” That’s the intended order if you’re building from scratch or onboarding a new team.

Or you can jump directly to the pattern that matches the problem you’re facing this week. Dealing with a multi-agent mess? Go to #15. Need to add human approval to a risky workflow? Go to #11.

Either way, each post will clearly call out how the pattern composes with the ones that came before it. Over time, that gives you your own internal library of agentic designs — tailored to your stack, your domain, and your actual constraints.

Let’s start at the very beginning: an ABCKart customer service rep opens their inbox at 9am to 127 unread messages across email, WhatsApp, and three marketplace portals. What happens when you just call the model directly — no tools, no memory, no orchestration — and how far does that actually get you?

What We’re Building at Flytebit

At FLYTEBIT Technologies, we design and ship agentic AI systems that handle real production workflows — replacing manual, fragmented processes with agents that reason, act, and coordinate across the tools and data your business already runs on.

We work with teams who want to move beyond demos and build systems that are reliable, observable, and safe to hand over to production.

Ready to get started?

• Visit us at: flytebit.com
• Follow FLYTEBIT TECHNOLOGIES on LinkedIn for insights and updates
• Schedule a free consultation to discuss your agentic AI architecture

Related Reading

Before diving into patterns, make sure you have the foundations:

👉 How AI Agents Actually Work: A Technical (But Accessible) Guide

The five core components every AI agent is built on — Perception, Reasoning, Planning, Action, and Learning — explained clearly with real examples.

Understand why this matters to your business:

👉 Why Agentic AI Matters Now — More Than Ever

Why the next 2–3 years separate leaders from laggards, and why building the right systems today is the only move that makes sense.

Key Takeaways

• ✅ Patterns, not frameworks: Every example is plain Python — no orchestration libraries. Understand the mechanic first; any framework is just a delivery choice on top
• ✅ Start simple: Most production problems are solved between patterns 1–6; resist complexity until the simpler version has failed you
• ✅ Composability is the goal: The real power comes from knowing which 2–3 patterns to combine — and which to leave out
• ✅ Built for shipping: Every post includes a design checklist you can copy directly into your design doc and adapt
• ✅ Safety, observability & governance covered at the design level: Every post covers these in depth — the companion code focuses on pattern mechanics only, so you can choose the tooling that fits your stack