Practical Applications

Now convert architecture into repeatable workflows that solve real user tasks.

Each workflow should define input, decision points, tool calls, and measurable outcomes.

In this repository, the practical path is deliberately simple: the FastAPI endpoint receives a prompt, handle_prompt routes it, the calculator tool executes, and memory plus tracing capture what happened.

Example workflow pattern

flowchart TB
    P[Prompt Intake] --> C{Classify Intent}
    C -->|Math| T1[Calculator Tool]
    C -->|Knowledge| T2[Retriever Tool]
    C -->|Unknown| F[Fallback Response]
    T1 --> M[Save to Memory]
    T2 --> M
    F --> M
    M --> R[Return Response]

    style P fill:#1976d2,color:#fff
    style C fill:#1976d2,color:#fff
    style T1 fill:#ff9800,color:#fff
    style T2 fill:#ff9800,color:#fff
    style F fill:#ff9800,color:#fff
    style R fill:#1976d2,color:#fff

Application scenarios

Scenario	Tooling need	Success metric
Internal assistant	Multi-tool routing and memory	Reduced manual lookup time
Dev support bot	Deterministic tool calls with audit trail	High answer consistency
Incident helper	Tracing and low-latency fallback	Mean time to diagnose drops

Source-aligned workflow examples

Workflow	Code path	Expected behavior
Simple math request	src/api/server.py → src/core/engine.py → src/llm/router.py → src/tools/calculator.py	Returns 5 for a prompt containing add
Audit trail capture	src/core/engine.py → src/memory/store.py + src/observability/tracer.py	Saves the prompt/response pair and prints a trace record
Unknown intent	src/llm/router.py → src/core/engine.py	Returns "No suitable tool found" when no keyword matches

Deployment-readiness signals

Signal	Good threshold	Why it matters
Route confidence	Stable above baseline in evaluation set	Indicates predictable tool choice
Tool error rate	Low and non-increasing	Prevents hidden quality regressions
P95 latency	Within user SLA	Preserves usability during load spikes

Practical hardening opportunities

Opportunity	Why it helps	Current starting point
Add route schemas	Prevents brittle keyword-only matching	route uses one if 'add' in prompt branch
Persist memory	Keeps conversation history across restarts	MemoryStore is currently in-memory only
Structured traces	Improves incident analysis	trace currently prints dictionaries

What is the fastest way to validate a practical workflow?

Build a narrow end-to-end slice first with one prompt type and one tool. Then add one complexity dimension at a time, such as memory or extra tools.

Should one workflow own multiple tools?

Yes, if the orchestration remains understandable and test coverage is explicit. If ownership becomes unclear, split workflows by business domain.

What makes the current demo workflow useful for learning?

It shows the full chain from request to tool execution with very little code. That makes it easy to trace where routing, storage, and observability fit.

--8<-- "_abbreviations.md"