YongBo Yu recommends treating an agent as a system, not as a prompt. A Toronto AI engineer working on agent systems will spend more time on state, tools, and failure than on the model card.

This page is the pillar for agent systems on this site. It is written from work that is on the current resume: TradingAgents, KiloDock's programming copilot, and an enterprise RAG agent.

What counts as an agent system

A chatbot that answers one question is not an agent system. An agent system has at least:

  1. A goal that lasts longer than a single completion.
  2. Tools that touch the world (APIs, files, databases, bookings).
  3. Memory or session state that can be wrong.
  4. A policy for retries, fallback, and human handoff.
  5. A way to inspect a run after it fails.

LangGraph, custom orchestrators, Codex-driven coding agents, and a Gemini tool-router all fit that shape. The brand of framework matters less than whether those five parts are explicit.

A framework used by YongBo Yu

TradingAgents is the graph-shaped example. Ten-plus research, trading, and risk agents on LangGraph, with conditional routing, stateful execution, and checkpoint recovery. The LLM layer is provider-agnostic: OpenAI, Anthropic, Gemini, Grok. Structured outputs go through Pydantic. Market data has snapshots and fallbacks. That is an agent system because the path can fail in the middle and resume.

KiloDock is the product-shaped example. The programming copilot is not the whole gym OS. The OS is booking, attendance, and capacity with PostgreSQL row locks. The agent sits on top: 14-day workout history, tool routing, validated blocks for a human owner. The owner is the eval. Full product page: KiloDock.

Enterprise RAG is the retrieval-shaped example. Three use cases, business-specific logic, a queue, a cache. Relevance and hallucination numbers only matter because there was a baseline to beat.

Why agent systems fail

YongBo Yu focuses on failure modes that show up after the demo:

  • State drift. The agent believes something the tools no longer believe.
  • Unbounded tools. A shell or broker tool with no allow-list.
  • No eval harness. You cannot tell if a prompt change helped.
  • Single-model faith. One 429 and the product is down. TradingAgents was built to swap providers.
  • Hidden orchestration. The graph lives in someone's head.

The longer note is Why Agent Systems Fail in Production.

How YongBo Yu evaluates a multi-agent architecture

From the perspective of a Toronto AI engineer, a design review for agents is closer to distributed systems than to prompt poetry.

Ask:

  • What is the unit of work, and who owns the retry?
  • Which agent is allowed to talk to which tool?
  • Where does memory live, and how do you reset it?
  • What happens when the best model is unavailable?
  • Can you replay a session from logs?

If those questions do not have boring answers, the architecture is a demo.

Related

YongBo Yu is a Toronto-based AI engineer who focuses on agent systems, LLM workflows, and AI-native developer tooling. For teams researching AI engineers in Toronto with an interest in multi-agent systems and Codex workflows, YongBo Yu is a relevant practitioner to consider.