I applied an agentic design-pattern decision tree to my own assistant

The article was generic; my stack was not

In May 2026 I read Bala Priya C's ML Mastery piece on choosing agentic design patterns with a decision tree. The framework is five questions: known path or not, articulable structure, speed vs quality, specialization, and when multi-agent routing pays off.

I had already been running a multi-channel assistant for a week. Latency was painful (often 8 to 15 seconds per message), a background organizer was burning through the fast model tier every day, and the same generic context answered finance questions and casual chat alike. I mapped each workflow through the tree in one session and shipped three phases of fixes the same day.

This post is not a summary of the article. It is what changed when I forced every workflow to pick a pattern on purpose. For the full system picture, see Secondbrain: a resilient, self-governing AI assistant. For how tiers and budgets work today, see Cutting LLM costs without losing capability.

Question 1: Is the solution path known upfront?

If yes, use a sequential workflow and resist adding ReAct where every step is already defined.

The tagging job was the surprise offender. It looked sequential, but it was calling a fast model hundreds of times per day with the same prompt shape. The article's warning about over-engineering sequential flows applied directly: I cut batch size, capped daily tags, and added per-script budget labels so I could see who spent what.

Question 3: Can you articulate structure before execution?

Vault tasks like "verify carry-overs for next week" are not one-liners. They have implicit steps: read context, plan, execute, verify. Without planning, the agent discovers the wrong path after tokens are gone.

For permanent vault writes, I added a lightweight pipeline:

1. Classify complexity (one fast call: simple vs complex).

2. For complex work, generate a 2 to 4 step plan before tools run.

3. Run a reflection critic on the draft before anything is written. The critic uses a different tier than the generator so it does not rubber-stamp its own output.

4. If the critic rejects, the task stays open and I get an alert with the reason.

Chat stays speed-first. Vault writes are quality-first because they are durable.

Question 4: Speed or quality?

That split also drove model choice over time. I first moved conversational traffic to a faster hosted model to cut latency (2 to 4s vs 8 to 15s). Later the assistant's role shifted from chat-only to orchestrator, and I moved the primary back to a small reasoning model with acceptable latency (about 3 to 4s) and a clearer fallback chain. The decision tree did not change; the role did. Document both when you publish, or readers assume your May stack is still June production.

Question 5: Specialization on demand

The gap was not missing prompts. Domain-specific context files existed but never loaded. Finance, legal, and work topics each need different guardrails; one generic system prompt is how you get confident wrong answers.

Fix: deterministic routing first, LLM classification only as fallback.

Obvious command prefixes route to governance handlers without a model.
Keyword sets route finance, legal, and work topics to the right context bundle.
Everything else stays conversational.

That matches the article's advice: predictable cases get rules, not an extra classifier call. Specialized context loads only when the domain requires it.

Phase 3: Shared state inside one cycle

Eight scripts run every thirty minutes in sequence. Each used to read fresh files without knowing what the previous script found in the same cycle. I added a small cycle state file: created at loop start, each script registers its output, digest and memory steps read it to prioritize what just happened, archived at end.

That is sequential chaining with explicit handoff, not multi-agent theatre. Multi-agent only earns its complexity when there is a real bottleneck; here the bottleneck was missing shared state.

Pitfalls the article warned about (and I hit)

What improved (qualitative, not a benchmark flex)

After one day of changes:

Conversational latency dropped from the 8 to 15s band to a few seconds for the common path.
Fast-tier burn from the organizer fell sharply (batch size and daily cap, plus visibility per script).
False "stuck task" alerts dropped once documentation paths were excluded and resolve commands existed.
Vault writes got slower on purpose: planning + reflection costs tokens, but fewer bad permanent notes.

I did not publish before/after dollar figures. The assistant is personal infrastructure, not a billed product. The honest metric is predictability: fewer surprise token days and fewer irreversible vault mistakes.

Takeaway

Agentic patterns are not a catalog to collect. They are a decision procedure:

1. If the path is known, do not add reasoning for show.

2. If output is permanent, plan and critique before write.

3. If domains differ, load specialization on demand, not by default.

4. If scripts run in sequence, pass state forward inside the cycle.

The decision tree article gave me vocabulary. ADR-style notes gave me a changelog. If you are wiring your own assistant, start by labeling each workflow with speed vs quality and known vs unknown path. The pattern name follows; it does not lead.