140 Concept Cards to Master Agent Development: The Knowledge Foundation for Interviews and Production

From Chatbots to Industrial-Grade Agents: Where's the Knowledge Gap?

Most people's understanding of AI Agents still stops at "a chatbot that can have conversations." But anyone who has actually done Agent development knows there's an entire complex ecosystem of engineering concepts underneath. A Bilibili creator shared a particularly valuable experiment: he fed multiple production-grade Agent products into an automated analysis tool called Hermes, letting the model autonomously extract and organize a concept card system.

The system has so far produced 140 concept cards, from C001 to C140, and is still running and being refined. The creator's core message is direct: if you're going to work in Agent development, these 140 concepts are the baseline knowledge you need to know — and possibly memorize.

Concept Cards Aren't Rote Memorization: A Causality-Driven Approach to Knowledge

This material is fundamentally different from the "one-liner explanation" resources you can find anywhere online. The creator set strict constraints in his prompts, ensuring each concept card isn't just an isolated definition, but is organized around causal relationships.

Each concept card includes the following dimensions:

• Name and synonyms: The same concept may go by different names across different repositories and products — unified recognition is essential
• Where it was extracted from: The actual physical artifact, the reference source, which file and which function
• What task it serves: Which tasks become impossible or degrade without this concept
• What forced it into existence: This is the main thread — every concept is an inevitable product of some constraint
• Reinforcement/conflict relationships: Who it complements, who it creates tension with, and what the trade-offs are

The creator placed particular emphasis on one methodological prohibition: frequency of occurrence must not be used as evidence of importance. Large models have a tendency toward "sincerity bias" — they like to count how many Agents a concept appears in, treating higher frequency as higher importance. But the opposite can be true: some concepts may appear in only one or two Agents yet represent critically important, forward-looking design decisions. The minimalist pi-agent, for example, naturally lacks many concepts — using frequency to judge stability leads you completely astray.

A Concrete Example: The Causal Chain of Context Caching

The "forced into existence by causality" logic behind these concept cards is best illustrated with a concrete example. Take prefix caching in long-running tasks:

Every round of a long-running task requires resending the entire history. Unchanged prefixes are billed at the cached rate, but the moment history is modified, the entire segment must be recalculated at the uncached rate. This difference shows up directly on the bill and in latency — a cache hit might take milliseconds, while a miss can take seconds to tens of seconds, doubling both cost and time.

This constraint then "forces out" the next layer of design: history bytes must follow append-only discipline, and IDs for the same file must use deterministic suffixes rather than random IDs. The reinforcing effect is that cache hit rates improve, costs drop, latency decreases — and in turn, append-only history becomes more predictable.

This is the essence of the entire card system: you're not memorizing an isolated term — you're understanding why it exists, who it affects, and how it's implemented across multiple real products. Being able to articulate this causal chain in an interview feels entirely different from rote memorization.

Prefix Caching is a critical optimization technique in large model inference services. When a model processes input, it computes the token sequence layer by layer into KV (Key-Value) caches — this is the primary source of inference latency and compute cost. The principle of prefix caching: if consecutive requests share the same beginning (the "prefix"), the inference service can retain the KV cache for that prefix and reuse it for subsequent requests, skipping redundant computation. This is extremely important in Agent scenarios — system prompts and accumulated conversation history often make up the vast majority of the input and remain unchanged across multiple interactions. When a cache hit occurs, inference time can drop from seconds to milliseconds, and billing is dramatically reduced (cached pricing across providers is typically one-tenth or less of uncached pricing). However, prefix caching is highly sensitive to input stability — modifying or inserting even a single token in the prefix invalidates the cache, forcing everything downstream to be recomputed. This is precisely why engineering practices give rise to constraints like "append-only discipline" and "deterministic IDs."

The Knowledge Map Across 140 Cards

Based on the creator's overview, this concept system covers virtually every engineering dimension of Agent development:

• Computation loop layer: turns, loops, continuation conditions, termination reasons, turn limits, over-limit handling
• Context management layer: compression, sliding window, summarization, prefix stability
• Message structure layer: role tags, tool definition schemas, tool result channels, execution result backfilling, vendor-specific interface implementations like DeepSeek^Ad (whether a field goes in the message segment or a dedicated segment)
• Tools and workspace layer: tool registration, directory management, permissions, sandboxing
• Memory layer: long-term memory, real-time extraction, forgetting, reset
• Multi-agent layer: sub-agents, multi-agents, pi-agents, context branching, pi depth, persona, human-in-the-loop, graph nodes and numbering, shared state and consensus, task decomposition and reallocation, workspace isolation
• Cost and governance layer: concurrency limits, deletion total limits, pricing systems, cost estimation

The creator also noted that this system starts from vendor physical interfaces — because large models are "physically real but constrained," and deviating from the API leads to broken behavior. So the cards include interface-level analysis for specific vendors like DeepSeek; when using other model providers, the same methodology can be re-applied from scratch.

The pi-agent (also written as π-agent) mentioned in the article is a minimalist reference architecture in Agent research — an implementation deliberately stripped down to the smallest possible feature set, retaining only the core reasoning loop and removing memory, tool registration, multi-agent coordination, and most other layers. Its value isn't practical utility, but rather serving as a "baseline control group": by observing where an Agent with almost nothing fails, you can reverse-engineer what real constraint each concept that gets "added back" actually solves. This also explains why the article stresses that frequency of occurrence cannot be used to judge importance — pi-agent naturally lacks the vast majority of concepts, so if frequency were the standard, designs that never appear in minimal implementations but are indispensable in high-complexity scenarios would be systematically undervalued.

Just the Starting Point: Beyond Concepts — Intent and Engineering Implementation

The creator also honestly acknowledged the limits of this material. He stressed that this only covers the concept side (A for Agent) — knowledge at the "rote memorization" level. Being able to answer a concept question well in an interview is still far from handling real requirements.

Actual production implementation requires additional capabilities: intent design, system prompt engineering, methodology, and ontology modeling. Interestingly, his advice is to solidify the conceptual foundation first — once you truly understand the nature of all the constraints, ontology work becomes less overwhelming. When you hit implementation problems, you'll find there's "no choice, it can only be done that way," which actually leads to deeper understanding.

He draws an analogy: just as a Java architect needs to have read through ten source codebases — Spring, SpringBoot, SpringCloud, Redis, and more — before calling themselves an architect, AI application and Agent developers who haven't done systematic analysis of a large number of real products and frameworks will always "lack grounding and credibility" in the field.

Ontology Modeling originates from knowledge engineering and philosophy. In the AI engineering context, it refers to the process of formally defining the concepts, entities, relationships, and constraints of a given domain — essentially specifying "what exists in this system, how things relate to each other, and what operations are valid." In Agent development, ontology determines how tasks are decomposed, how tools are described, and how state is represented — it's the upstream thinking that shapes system prompt and tool schema design. It's difficult because it requires simultaneously understanding the semantic boundaries of the business domain and the cognitive limitations of the model. Definitions that are too broad cause the model to get lost in ambiguity; definitions that are too granular sacrifice generalization. This is precisely why the creator recommends thoroughly internalizing the constraint-based concepts first (those 140 cards): once you truly understand the physical constraints of context windows, billing structures, and tool-calling protocols, many "multiple choice" questions in ontology modeling simply disappear — most ambiguities can't survive contact with real constraints.

Value and Limitations

The greatest value of this concept system — generated by an automated tool — lies in its methodology: using real production products as the data source, organizing knowledge by causal relationships rather than frequency of occurrence, and reverse-engineering design decisions from the physical constraints of vendor interfaces. This approach itself is worth borrowing by every Agent developer.

That said, the limitations are worth acknowledging: the content is still being generated (it wasn't complete at the time of sharing), the creator himself admits the visualization graphs (DAGs, tension diagrams) are "not very pretty," and given how quickly large models evolve, the concept system needs continuous updating. But as the creator notes, once this foundation is in place, the pace of subsequent additions accelerates significantly.

For anyone preparing for interviews or learning Agent development from scratch, thoroughly internalizing the causal logic behind these 140 concepts will build a knowledge foundation far more solid than scattered resources ever could.