Building an Intelligent Food Safety Inspection Router with LangGraph

How I Automated Restaurant Violation Triage Using Multi-Agent Orchestration

TL;DR

I built InspectFlow-AI as a personal proof-of-concept to explore a problem I kept noticing in public-health inspection workflows: the hard part is rarely capturing violations on site, but rather the hours of sorting, severity scoring, and regulation lookup that follow. This experimental project routes restaurant health inspection findings through a LangGraph-orchestrated multi-agent pipeline backed by FastAPI and a lightweight FDA Food Code knowledge index. Each violation passes through classifier, severity, regulation retrieval, and action-planning agents before landing in a structured triage report with follow-up timelines. The full source code lives at https://github.com/aniket-work/InspectFlow-AI. In my opinion, the most interesting takeaway is not any single agent prompt, but how graph-based orchestration keeps specialist steps composable without turning the codebase into spaghetti. This write-up documents my design choices, the code I wrote along the way, and what I would change if I extended the PoC further.

Introduction

A few months ago I started paying closer attention to how inspection findings travel from a field notebook to a corrective-action letter. From my experience reading anonymized public health reports, the narrative is always clear on site: a walk-in cooler reading, a sanitizer strip failure, pest evidence behind dry storage. What is less visible in those PDFs is the downstream labor. Someone has to decide whether a 48-degree cooler is a critical temperature violation or a major one depending on context, attach the right Food Code citation, and estimate how quickly the establishment must respond before re-inspection.

I wanted to test whether multi-agent orchestration could compress that downstream work without pretending to replace human judgment. InspectFlow-AI is the result of that experiment. It is not production software, not something I deployed at any employer, and not a claim about how health departments should operate. It is a solo PoC I built to learn LangGraph patterns in a domain that felt concrete and underserved in agent tutorials.

The architecture rhymes with other business automation platforms I have experimented with: specialist agents, a coordinator, a knowledge layer for retrieval, and a thin API for integration. I deliberately chose food safety rather than finance, logistics, or hiring because those domains are overrepresented in demo projects, and because inspection triage has crisp inputs and outputs that make evaluation honest.

What pulled me toward this domain specifically was the asymmetry between field work and desk work. On site, inspectors follow a checklist mindset. Back at the office, the same findings become a prioritization problem: which violations could cause illness if ignored for seventy-two hours, which are paperwork gaps, which require immediate closure versus a scheduled re-visit. I wondered whether explicit agent roles could mirror that mental sorting without hiding reasoning inside a black-box model.

I also wanted a use case where mistakes are obvious. If an agent labels a mouse dropping as advisory, tests should scream. That clarity helped me iterate faster than I would have in a vague “business insights” demo where quality is subjective.

What's This Article About?

This article walks through how I designed and implemented InspectFlow-AI, a multi-agent system that ingests batches of restaurant inspection violations and emits triage reports containing category labels, severity scores, regulatory references, recommended corrective actions, and follow-up windows. You will see the LangGraph state machine I used, the specialist agents I wrote, the regulation knowledge module that acts as a stand-in for retrieval-augmented generation, and the FastAPI surface that exposes the workflow to a simple dashboard.

I also cover setup and execution steps so you can reproduce the PoC locally, and I share edge cases I discovered while testing, including ambiguous violations that fooled the classifier and severity heuristics that needed tuning. Throughout, I frame conclusions as personal observations from an experimental build rather than authoritative guidance for regulated environments.

Tech Stack

I kept the stack intentionally small. Complexity in agent systems often hides in dependencies long before it hides in prompts, and I wanted to feel every layer.

1. Python 3.11 as the runtime. Strong typing with Pydantic models made violation batches easy to validate at API boundaries.
2. LangGraph for orchestration. I considered a hand-rolled coordinator loop, but LangGraph gave me explicit state transitions and a graph I could diagram without lying.
3. FastAPI for HTTP endpoints and to serve a minimal HTML dashboard from the same process.
4. Pydantic v2 for schemas such as InspectionViolation, TriageResult, and BatchTriageReport.
5. Rich for CLI tables. Terminal output matters in inspection workflows because many public-health tools still live partly in terminals and CSV exports.
6. Matplotlib for severity and category distribution charts. I wanted at least one visual summary of learned triage statistics, not because the charts are fancy, but because they make batch behavior obvious at a glance.

I skipped a full vector database in this PoC. A lexical regulation index was enough to prove the RAG insertion point, and it kept the repository approachable for readers who want to clone and run in ten minutes.

As per my experience shipping small services, I optimize for clone-to-green time in PoCs. Every extra infrastructure component is a reader who bounces at step four of the README. LangGraph plus FastAPI plus a JSON fixture gets people to a colored terminal table quickly. That table is the emotional payoff that convinces someone to read the rest of the design sections.

Component	Role in InspectFlow-AI	Why I chose it
LangGraph	Batch violation loop	Makes orchestration visible and testable
FastAPI	HTTP + static dashboard	Single process dev experience
Pydantic	Schema guardrails	Prevents malformed batches early
Rich	CLI tables	Matches analyst-friendly output
Matplotlib	Severity charts	Quant summary for README and article

Why Read It?

If you are experimenting with LangGraph and tired of toy chatbots, inspection triage offers a disciplined sandbox. Inputs are structured sentences. Outputs are enums, citations, and action lists. That makes it easy to tell when an agent misbehaved without hand-waving about subjective quality.

From my perspective, three ideas in this PoC transfer to other domains:

1. Specialist agents beat monolithic prompts when each step has different failure modes. Severity scoring and regulation lookup should not share one prompt context window.
2. Graph orchestration documents business process better than nested if-statements. Health departments already think in workflows; LangGraph mirrors that honestly.
3. A thin API unlocks multiple clients with one workflow. I used both a Rich CLI and a browser dashboard against the same triage function.

The GitHub repository at https://github.com/aniket-work/InspectFlow-AI includes tests, sample data, diagrams, and a title animation GIF generated from terminal output plus a dashboard preview. Clone it, run python main.py, and you will see the same ASCII table aesthetic I embedded in the article cover animation.

Let's Design

Before writing code I sketched the lifecycle of a single violation. An inspector records a finding. A triage system must answer four questions: what type of risk is this, how severe is it right now, which regulations apply, and what corrective path closes the gap fastest. Those questions map cleanly to four agents plus a coordinator.

Coordinator and state

The coordinator owns batch progress. LangGraph state carries the violation list, accumulated results, establishment name, and a numeric index. I chose explicit index-based iteration rather than recursive graph tricks because it made debugging easier when a single violation produced surprising output.

Classifier agent

The classifier maps free text into a ViolationCategory enum: temperature control, cross-contamination, pest control, employee hygiene, equipment sanitation, documentation, allergen handling, or water quality. I used keyword scoring rather than an LLM because I wanted deterministic tests. In a later iteration I would hybridize: rules for high-confidence patterns, LLM fallback for ambiguous notes.

Severity agent

Severity is where public-health risk actually lives. A missing temperature log is not the same as active pest evidence. I encoded heuristics such as detecting 48F in cold-hold descriptions, cross-contamination during service, or rodent droppings. The agent emits critical, major, minor, or advisory. This is the step I would be most cautious about deploying without human review, which is why the PoC prints confidence scores and agent traces.

Regulation agent

This agent queries a small FDA Food Code chunk index. Each chunk includes a code, title, body, and category tag. Search is lexical overlap with a category boost. It is a deliberate stand-in for embedding retrieval, but the interface is stable: pass description and category, receive citation strings.

Action planner agent

Finally, the planner converts category and severity into recommended corrective steps and a follow-up day count. Critical temperature issues suggest product disposition and next-day re-inspection. Pest evidence triggers licensed pest control within twenty-four hours. The planner is where I encoded operational knowledge that inspectors already apply intuitively.

API and clients

FastAPI exposes /api/triage/sample for the bundled dataset and /api/triage for custom payloads. The root route serves a dark-themed dashboard that renders severity cards and a category bar chart after a POST call. I put the frontend in a single HTML file to avoid Node build tooling in a PoC README.

Let's Get Cooking

Here is where I translate the design into code. I split the implementation into schema models, specialist agents, the LangGraph workflow, and the API layer. I wrote each block to be readable in isolation because, in my experience, agent repos rot quickly when everything lives in one thousand-line module.

Data models

I started with Pydantic models because violation batches arrive from JSON exports in real life, and I wanted validation before any agent touched the data. Strong typing also made FastAPI response models trivial to declare.

class Severity(str, Enum):
    CRITICAL = "critical"
    MAJOR = "major"
    MINOR = "minor"
    ADVISORY = "advisory"

class InspectionViolation(BaseModel):
    violation_id: str
    establishment: str
    description: str
    observed_at: str
    inspector_notes: str = ""

class TriageResult(BaseModel):
    violation_id: str
    category: ViolationCategory
    severity: Severity
    regulation_refs: list[str] = Field(default_factory=list)
    recommended_actions: list[str] = Field(default_factory=list)
    follow_up_days: int
    confidence: float = Field(ge=0.0, le=1.0)
    agent_trace: list[str] = Field(default_factory=list)

These models became the contract between CLI, API, and agents. Keeping enums strict prevented silent string drift in severity labels when I generated charts later.

Specialist agents

Each agent appends to an agent_trace list so I could explain decisions in the CLI and in future audit logs. The classifier scores keyword hits per category:

def classify_agent(violation: InspectionViolation, trace: list[str]) -> ViolationCategory:
    text = f"{violation.description} {violation.inspector_notes}".lower()
    best_category = ViolationCategory.HYGIENE
    best_score = 0
    for category, keywords in CATEGORY_KEYWORDS.items():
        score = sum(1 for kw in keywords if kw in text)
        if score > best_score:
            best_score = score
            best_category = category
    trace.append(f"ClassifierAgent: mapped to {best_category.value} (score={best_score})")
    return best_category

Severity logic encodes the public-health intuition I mentioned earlier. For example, cold holding above 45F becomes critical, while incomplete weekend temperature logs stay minor. I put it this way because severity mistakes are costlier than category mistakes: they directly influence re-inspection urgency.

The regulation agent wraps the knowledge search:

def regulation_agent(category: ViolationCategory, violation: InspectionViolation, trace: list[str]) -> list[str]:
    hits = search_regulations(violation.description, category=category.value, top_k=2)
    refs = [f"{h.code}: {h.title}" for h in hits]
    trace.append(f"RegulationAgent: retrieved {len(refs)} code references")
    return refs

The action planner returns both steps and follow-up days. That pairing is what makes the output feel operational instead of academic.

LangGraph workflow

The graph is small but worth showing because it is the spine of the PoC:

def build_triage_graph() -> Any:
    graph = StateGraph(TriageState)
    graph.add_node("load", _load_batch)
    graph.add_node("process", _process_next)
    graph.add_node("summarize", _summarize)
    graph.set_entry_point("load")
    graph.add_edge("load", "process")
    graph.add_conditional_edges(
        "process",
        _should_continue,
        {"process": "process", "summarize": "summarize"},
    )
    graph.add_edge("summarize", END)
    return graph.compile()

Each pass through process triages one violation and increments the index. When the index reaches the batch length, the graph routes to summarize, which is a hook I left open for aggregate analytics such as average confidence or category histograms.

run_batch_triage computes severity counts and category distributions after the graph finishes. That summary feeds both the Rich CLI table and the Matplotlib chart in src/analytics.py.

FastAPI surface

The API is intentionally thin. It validates payloads, calls run_batch_triage, and returns a BatchTriageReport. The sample endpoint loads data/sample_violations.json, which describes eight findings at a fictional bistro: an overloaded cooler at 48F, unsanitized board use, low sanitizer ppm, bare-hand contact with ready-to-eat food, a missing tree-nut allergen declaration, a slow drain, incomplete hot-hold logs, and mouse droppings behind dry storage.

@app.post("/api/triage/sample", response_model=BatchTriageReport)
def triage_sample() -> BatchTriageReport:
    violations = sample_violations()
    return run_batch_triage(violations)

I wired CORS permissively because this is a local PoC dashboard, not a public deployment. If I hardened the experiment, authentication and establishment tenancy would come first.

Batch aggregation logic

After the graph finishes, run_batch_triage aggregates severity counts and category histograms. This function is plain Python on purpose; not every step needs to be a graph node. I kept summarization outside the loop so unit tests can call triage_violation directly without invoking LangGraph when I want faster feedback.

def run_batch_triage(violations: list[InspectionViolation]) -> BatchTriageReport:
    graph = build_triage_graph()
    final = graph.invoke({
        "violations": violations,
        "results": [],
        "establishment": violations[0].establishment,
        "index": 0,
    })
    results: list[TriageResult] = final["results"]
    counts = {s: 0 for s in Severity}
    category_counts: dict[str, int] = {}
    for r in results:
        counts[r.severity] += 1
        category_counts[r.category.value] = category_counts.get(r.category.value, 0) + 1
    return BatchTriageReport(
        establishment=violations[0].establishment,
        processed=len(results),
        critical_count=counts[Severity.CRITICAL],
        major_count=counts[Severity.MAJOR],
        minor_count=counts[Severity.MINOR],
        advisory_count=counts[Severity.ADVISORY],
        results=results,
        summary_stats={
            "avg_confidence": round(sum(r.confidence for r in results) / len(results), 2),
            "avg_follow_up_days": round(sum(r.follow_up_days for r in results) / len(results), 1),
            "category_distribution": category_counts,
        },
    )

The summary statistics feed the dashboard bar chart and the README analytics image. When I first omitted category_distribution, the UI felt empty even though per-row triage was correct. Aggregates matter for human scanability.

CLI presentation layer

main.py uses Rich tables because inspection analysts often work from tabular summaries. I print establishment name, severity counts, and per-violation rows with color-coded severity. The CLI became the source of truth for the GIF animation frames, which keeps marketing assets honest.

What surprised me during implementation

When I first ran the batch, pest-related keywords in a slow-drain note caused a false pest classification. I tightened category keyword lists and prioritized temperature regex matches. Another surprise: confidence scoring felt too flat when every result returned the same value. I added small boosts when regulation hits exist and when severity is critical or major, which better reflected my own certainty when testing.

Let's Setup

Step-by-step details can be found at the repository README: https://github.com/aniket-work/InspectFlow-AI

Locally, the setup path I used looks like this:

1. Clone the repository and create a virtual environment inside the project root.
2. Install dependencies from requirements.txt, which pins LangGraph, FastAPI, Rich, and Matplotlib among others.
3. Run python main.py to triage the sample JSON batch and print the Rich summary table.
4. Optional: start uvicorn inspectflow.api.server:app --app-dir src --reload and open the dashboard at port 8000.
5. Optional: execute pytest tests/ -v to confirm critical pest violations and action list presence.

I recommend keeping the virtual environment inside the repository folder for PoCs like this so paths to data/sample_violations.json remain predictable when you run scripts from different working directories.

Environment variables are not required for the default demo. If you extend the project with embedding-based retrieval or an external LLM provider, add keys through a .env file but do not commit secrets.

Let's Run

Running python main.py against the bundled dataset typically reports eight processed violations with three critical and five major findings in my latest run. Critical items included the 48F cooler, cross-contamination during salad prep, and mouse droppings. Average confidence landed around eighty-five percent with an average follow-up window near five days.

The CLI output ends with an ASCII-friendly table that mirrors what I animated in the repository GIF. That was intentional: I wanted the marketing asset and the actual tool output to tell the same story.

For API mode, POST /api/triage/sample returns JSON containing per-violation recommended_actions and regulation_refs. The dashboard renders severity cards and a horizontal bar chart of category distribution without a separate frontend build step.

To generate analytics assets, run python src/analytics.py. It writes images/triage-stats-chart.png, which I included in the README so GitHub visitors see quantitative behavior immediately.

When I demo this PoC to myself after a break, I use a three-step smoke path: CLI batch, pytest, then dashboard POST. That sequence exercises the graph, validation rules, and HTTP layer without needing external services. If all three pass, I trust the repository state enough to publish diagrams or write about it.

For readers who prefer API exploration with curl, curl -X POST http://localhost:8000/api/triage/sample returns the full BatchTriageReport JSON. I often pipe that output through jq to inspect a single violation’s recommended_actions array and verify regulation references attached correctly.

Edge Cases and Testing Philosophy

I wrote four pytest cases covering batch length, minimum critical detections, non-empty actions and regulation references, and a dedicated pest severity check. Tests encode what I care about in this PoC: pest evidence must never be downgraded quietly, and every triage result must be actionable.

Ambiguous notes remain a weakness. A slow drain with organic buildup sometimes scores against pest keywords even when no activity was observed. In production I would route low-confidence classifications to a human queue. Here, I expose agent_trace lists to make that queue possible later.

Temperature parsing only searches Fahrenheit patterns like 48F. Celsius-dominant jurisdictions would need parallel patterns. That limitation is acceptable in a US-focused demo but worth documenting honestly.

Walking Through a Sample Violation

To make the pipeline concrete, consider violation V-2026-0412-001 from the sample dataset: a walk-in cooler holding raw chicken at 48F when 41F or below is required. When I feed this batch through the graph, the coordinator hands the item to the classifier, which scores temperature keywords highest and maps the finding to temperature_control. The severity agent parses 48F, recognizes it exceeds the 45F critical threshold I encoded, and labels the item critical. The regulation agent retrieves FDA-3-401: Cold Holding Temperature because the description mentions cold holding and the category boost aligns. The action planner responds with product disposition, cooler load redistribution, calibrated probe verification, and a one-day follow-up window.

That end-to-end path takes milliseconds in my local runs, but the value is not speed. The value is repeatability. Every violation in the batch gets the same structured treatment, which means I can diff reports across code versions when I tune heuristics. When I adjusted pest keyword weights after a false positive on a drain note, I re-ran pytest and the CLI table immediately showed whether critical counts changed. That feedback loop is what I look for in agent PoCs.

Regulation Knowledge Base Design

I modeled the knowledge layer as a list of RegulationChunk dataclass rows rather than jumping straight to ChromaDB. Each chunk stores a code, title, body, and category tag. The search function tokenizes query and body text, counts overlap, and applies a category boost when the classifier label matches. This is intentionally primitive. From my experience building RAG demos, teams sometimes spend days on embedding pipelines before validating whether retrieval inputs are structured correctly. Here, the interface is stable: search_regulations(query, category, top_k).

If I swap in embeddings later, agents above the knowledge layer stay unchanged. That separation mattered to me because it mirrors how I would approach a production migration: nail schemas and agent IO first, upgrade retrieval second. The current index includes ten Food Code excerpts spanning temperature, separation, warewashing, handwashing, allergens, pests, plumbing, and record keeping. It is not exhaustive, but it is enough to prove citation attachment in reports.

Monolithic Prompt Versus Specialist Agents

Early in the experiment I tried a single prompt that asked for category, severity, citations, and actions in one JSON blob. It failed in boring ways: severity would be conservative when citations were verbose, and allergen issues were mislabeled as hygiene when glove notes appeared in the same sentence. Splitting responsibilities into agents eliminated most of that cross-talk. Each agent receives only the fields it needs, writes to agent_trace, and returns a typed value the coordinator merges.

This aligns with how I think about LangGraph more generally. Nodes are functions with narrow contracts. Edges express control flow a health department analyst could whiteboard. When I revisit the monolithic prompt idea, it will be as a final summarization layer, not as the core reasoning engine.

Dashboard and Visualization Choices

The HTML dashboard uses a dark theme with severity-colored badges because inspection software I have seen in demos often defaults to sterile white tables that hide urgency. I wanted critical items to visually pop. The category bar chart is simple horizontal bars rather than a heavy charting library. For this domain, showing that three violations clustered in temperature and pest categories is more useful than animating trends over time.

Matplotlib generates a static triage-stats-chart.png with severity and category subplots. I used dark backgrounds to match the dashboard and GIF aesthetic. Static charts export cleanly to README, which helps GitHub visitors who never run the code still grasp batch behavior.

Performance and Operational Notes

The sample batch of eight violations completes in under a second on my laptop, including graph orchestration overhead. I did not optimize for throughput because inspection batches in this PoC are tiny. If batches grew to thousands of historical findings, I would parallelize per-violation triage outside LangGraph or shard by establishment while keeping the same agent functions.

Memory footprint stays small because violations are pydantic objects in a list, not streamed from a warehouse. Logging is print-based in the CLI and trace lists in results. A next step would be structured JSON logs with violation IDs for observability, but I skipped that to keep the repository approachable.

Project Layout Rationale

I nested application code under src/inspectflow so imports read naturally in tests and uvicorn targets. main.py lives at the repository root because that is the entry newcomers type first. Sample data sits in data/ rather than inside tests/ so both the API and CLI can load the same fixture without pytest coupling. Images are checked into git because Dev.to and GitHub render raw URLs; binary assets must survive git push without .gitignore accidents, a lesson I learned from prior publishing attempts.

Theory Behind Follow-Up Windows

Follow-up days encode how quickly I believe an establishment must show correction before re-inspection risk rises. Critical temperature and pest findings map to one day in my heuristics because product disposition and pest control contracts cannot wait a business week. Documentation gaps map to fourteen days because they are serious but not immediate illness vectors. These numbers are not legal standards; they are PoC placeholders where I tried to mirror operational urgency I observed in public reports.

When I tune follow-up windows, I treat them like SLA fields in incident management. The agent planner returns integers, not prose intervals, so downstream schedulers can sort and filter mechanically.

Comparing Outputs Across Code Versions

One habit I kept from prior agent experiments is saving JSON reports when iterating heuristics. InspectFlow-AI supports --json-out on the CLI. Diffing two JSON files after a severity tweak shows exactly which violation IDs changed severity or follow-up days. That practice sounds tedious, but it prevented regressions when I fixed the drain false positive. Without structured output, I would rely on eyeballing terminal tables, which does not scale past a handful of violations.

Integration Points I Deliberately Left Open

The FastAPI layer returns pydantic-serialized JSON ready for webhooks, email workers, or PDF renderers I did not build. agent_trace arrays are the extension point for human review queues: a UI could highlight low-confidence rows or violations where classifier and severity agents disagreed with a prior human label. The regulation agent returns string citations today; tomorrow it could return structured objects with URLs to official code PDFs.

I also left authentication out entirely. If this ever faced real establishment data, tenant isolation and role-based access would precede any model upgrade.

Ethics and Boundaries

Automating inspection triage touches public health. I want to be explicit: this PoC does not grant establishments compliance, does not replace licensed inspectors, and does not connect to live government systems. It sorts text you give it. If someone deployed a derivative system, human review on critical severities would be non-negotiable in my view, and model or rule changes would require traceable versioning.

I also avoided implying employer affiliation. This build lives entirely in my personal GitHub namespace as an experiment.

Future Roadmap I Would Explore

If I continue this PoC, my next steps would be:

1. Replace lexical regulation search with embeddings stored in Chroma or pgvector, then measure citation precision against a held-out violation set.
2. Add an LLM summarization step that rewrites corrective actions into inspector-facing letter language while keeping structured JSON underneath.
3. Introduce establishment history so repeat violations escalate severity automatically.
4. Export PDF corrective-action drafts with regulation footnotes.
5. Build a feedback endpoint where a human reviewer marks agent mistakes, creating training data for later fine-tuning.

None of those are implemented here. They are the natural extension points I noted while writing the graph skeleton.

What I would not change

If I rebuilt the PoC from scratch, I would keep three decisions exactly as they are: strict pydantic schemas at the boundary, separate specialist modules instead of one prompt file, and agent_trace on every result. Those choices cost almost nothing in lines of code but paid off every time I debugged a surprising severity label.

Reader exercises

If you fork the repository, here are three exercises I found useful while learning:

1. Add a new violation to sample_violations.json with ambiguous wording and write a test that asserts your expected severity.
2. Introduce a fifth agent that drafts a plain-language summary paragraph per violation without altering structured fields.
3. Swap lexical regulation search for an embedding model and compare citation precision on ten hand-labeled examples.

Each exercise touches a different production concern: evaluation, human-readable output, and retrieval quality.

Closing Thoughts

InspectFlow-AI started as a question about downstream inspection labor, not as a pitch for autonomous government software. What I ended up with is a compact LangGraph workflow that feels honest about its limits: deterministic agents, explicit traces, readable tests, and a API that could swap underneath without rewriting business logic.

From my experience, the hardest part of multi-agent tutorials is not drawing boxes on a whiteboard. It is choosing a domain where evaluation is grounded. Food safety violations gave me that grounding. When the classifier mistyped a drain issue, tests failed or traces looked wrong immediately. When severity heuristics worked, the CLI table matched my own gut ranking.

If you are building your own orchestration experiments, steal the structure more than the rules. Keep schemas strict, keep agents narrow, keep orchestration visible, and keep humans in the loop for critical outcomes. The repository at https://github.com/aniket-work/InspectFlow-AI is there if you want to run the same path I did and remix it for a completely different compliance domain.

One last reflection: agent hype often focuses on autonomy. This project convinced me that disciplined routing is the more interesting problem. Inspection violations do not need a chatty assistant; they need reliable sorting, traceable reasoning, and fast handoff to humans when stakes are high. LangGraph helped me express that routing story in code without pretending the PoC is more than an experiment.

I will keep iterating on personal agent projects like this because each one teaches a reusable pattern. InspectFlow-AI’s pattern is narrow agents, explicit graph state, honest tests, and dashboards that mirror terminal truth. That combination is what I would carry into the next domain, whatever it ends up being.

Cover animation for readers who prefer visual summaries:

Disclaimer

The views and opinions expressed here are solely my own and do not represent the views, positions, or opinions of my employer or any organization I am affiliated with. The content is based on my personal experience and experimentation and may be incomplete or incorrect. Any errors or misinterpretations are unintentional, and I apologize in advance if any statements are misunderstood or misrepresented.