AI Agent / Developer workflowDeveloper talk
From tools to teammates

AI Agent:
Developer's "Silicon Teammate"
-- Advanced Version

From AI tool to AI teammate: AI Coding for Enterprise IT

Real tasksTool CallHuman review boundaries
AI
×
IT
CONTENT MAP44 PAGES / DETAILED INDEX

01 / Foundation and methodology

About me.P3
From answer to taskP4
Let's start with the mission.P5
Agent loopP6
First UseP7
It'll work soon.P8
ReliabilityP9
Maintenance of old systemsP10

02 / Skill and Team Experience

Turn experience into Skill.P11
Skill Best PractiseP12
Skill Best Practise / QualityP13

03 / Spec, Loop and Token

Spec-Driven DevelopmentP14
Minimum SpecP15
Split for Large SpecP16
Execute Spec with /goalP17
Agent loop: new functional developmentP18
Agent Loop: How to advance in an iterative fashionP19
Token Use Optimization: BudgetP20
Token use optimization: Codex and Claude CodeP21
Token Usage Optimization: Self-build AgentP22

04 / LLM Observability

On 3rd LayerP23
AutoGen Access ObservatoriesP24
From Trace to GuardrailP25

05 / Operating boundaries and development modalities

Borders and human trialsP26
Prompt Engineering to Graph EngineeringP27
Changes in working methodsP28
Three product development feedback cyclesP29
From tool to work streamP30
LLM hallucinationsP31

06 / Knowledge, Models and Multi-Agent

RAG: Access to knowledgeP32
RAG: Distillation LayerP33
LLM SelectionP34
Choosing the right agentic patternP35
Agent Design Pattern FrameworkP36
Tool selection for domestic developersP37
High Agent mode: circularP38
High Agent mode: layoutP39
Code and judgementP40
Multiple Agent how to communicateP41
AutoGen: Information CollaborationP42
LangChain / LangGraph: state collaborationP43
EndP44

This AI Agent Developer Team presentation is delivered in two sessions: Basic and Advanced.

03 / 44About me
About me.

From real work,Turn AI into a teammate.

Wade Deng Wei.
MaybeAI Co-founder & Technical Lead

Helps many businesses that collect hundreds of millions or millions of dollars a year across borders to land in AI.

X: @no7wadeWechat: @no7wade
RoadToAGI channel 2D
RoadToAGI · Scan QR code to view my channel
04 / 44Rethinking AI
Cognitive change

Chat AI is a good start,
but it should not be the end.

Past: One question.

I have a question.
↓
AI, give me an answer.

→

Now: One thing is done.

I have a goal.
↓
AI reads, changes, runs, and validates

05 / 44Tool Selection
No tools first.

First the mission, then the choice.
The most appropriate AI way.

Call LLMClassification, summary, translation, information extraction
Python / ShellDocumentation, data, logs, batch processing
Workflow / RPAFixed processes, cross-system moves
Coding AgentRead the code, change the bug, fill the test.
AgentComplex objectives, multi-step dynamic decision-making
Which AI tool is best?Instead: What is this mission? What's the best way to get AI to finish it?

Select enough models.
Strong reasoning is not equivalent to a high frequency small mission. Codes, speed, context, cost and tool callability are to be compared back to the real job.

06 / 44Rationale
Agent, why are you working?

It is not about better conversation.
It is an extraexecution loop.

01

Objective

You say what you want to achieve.

02

Planning

AI Dismantling Mission, deciding what to do first.

03

Tools

Read files, search, run commands, run tests.

04

Evidence

Seeing the real results, not guessing.

05

Next

Proceed with the results until acceptance.

Traditional chat:End of answer..
Agent:One step, one result and one next.
07 / 44The first real use of Agent
Start with a real mission.

Add an export function to the order moduleExport function.

01

First understand the item and find the relevant code to export the order. Tell me how I'm going to change it. Don't change it.

02

The programme can be modified. Change only the order module and not the database structure.

03

Run the test after the change is completed and tell me the results. If you fail, you analyse the causes and fix them.

/ AI work track read files → search code ↓ edit → run tests ↓ inspect evidence → fix ↓ report result
08 / 44Daily IT Job
We can start today.

Put AI in the job you're already doing.

Check, Bug.Analysis of the reasons before proposing changes.
Read the log.Looking for anomalies, categorizing, forming assumptions.
Check SQL.Parameters, data, implementation results.
ReconfigureLimiting documentation and permissible changes.
Look at the old code.Explain the call chain, focus no time.
Write ScriptLet Mr. LLM be a running version.
Add DocumentWrite down the context of the project.
Supplementary testingLet the results be accepted and accepted.

Three hints:Understand first. To the border. Let it verify.

09 / 44Make AI more reliable.
Not once.

I'm not sure if I'm going to write it.Certification mechanismsDecide if it can be delivered.

RequirementsClear results
→
AI ChangesChange
→
Run TestGet the evidence.
→
Failed feedbackExposure problems
→
Recovery and retestingUntil it's accepted.
Allow AI to make mistakes,
No evidence is allowed.

The context of the project should also sink.

README: What is the project, how it runs.
AGENTS.md: Which directories can be modified, how to run, and which operations must be identified.

10 / 44Maintainer Developer
Second eyes.

Debug is not an AI guess.
It's about making it.Position along the chain of evidence.

01 / Input

User phenomena, time of occurrence, request parameters, environment differences.

02 / Log

Error stack, upstream/downstream request, abnormal frequency, association ID.

03 / Assumptions

Possible causes, modules, key points for validation.

04 / Validation

Repeat, query data, run tests, confirm that there are no side effects.

Find evidence and make assumptions and test assumptions.One solution is to work, and it's the teammates who settle down.
11 / 44Turn experience into Skill.
From personal to team skills

Skill is not a Prompt collection.
It's...Executable, acceptable, reusableThe way.

01

scene

When?

02

Input

What do you need?

03

Process

What are the steps to be taken?

04

Conditions for discontinuation

What can't go on?

05

Output

What was the last delivery?

06

Receiving and Inspection

How do you judge success?

12 / 44Skill Best Practise
Before the trigger, the model saw only metadata

Skill Best Practice: Right first.I'm not sure.
And it's being properly implemented.

  • Keep it simple.Delete the common sense already known to the model; each paragraph should be worthy of the context.
  • Matches freedom.Inspired tasks give a high degree of freedom; there are templates in fixed mode; and vulnerable operations give precise steps.
  • Good metadata.Starts by preloading name + description; they decide whether Skill will be found and triggered.
  • Let content be maintained.Quote one layer, which is more descriptive; old methods are archived separately to avoid obsolescence of the main process.
  • Use progressive disclosure.Main SKILL.md maintains a streamlined and complete details are placed in the on-demand reference document.
  • Harmonization of terminology and examples.The same concept is referred to by only one name and the examples are specified; a default path is given and no too many options are listed.
# discoverability metadata name: analyzing-sales description: Analyzes sales data and builds reports. Use when users ask for revenue, pipeline, or performance analysis.
Read order:
On startup: preloadname + description
After Trigger: ReadSKILL.md
On demand: Readreference/Waiting for documents

Writing principles:descriptionWriting capability + trigger scene;step, boundary and acceptance In.SKILL.md.
13 / 44Skill Best Practise
Turn quality into visible feedback

The real quality comes fromTesting, validation and continuation.

  • Complex task-writing workflow.Clear, continuous steps and checklist to reduce the probability of missing steps.
  • Create feedback loops.Executing validation of fixation problems again until acceptance passes.
  • Sets a cessation condition for critical operations.High-risk, destructive or irreversible actions are planned for further implementation.
  • Output verifiable intermediate results.Bulk changes, form fillings, etc., are programmed, rechecked, executed, reviewed.
  • Script to solve the problem.Visible error of processing, explaining key parameters, listing dependency; do not throw problems back to the model.
  • Determines the operational priority tool.Directly running utility script is more reliable than every temporary generation code.
  • We'll make an assessment and write a long document.At least three scenarios are prepared, starting with a Skill baseline, and then testing different models and real missions.
  • Watching real use.Pay attention to missing references, re-exploring, neglected content and incorporating team feedback for continuous adaptation.
Don't write instructions on feelings, use real behavior.Watch → fix → retest.
14 / 44Spec-Driven Development
Write intent into a verifiable contract.

Spec is not a realization plan.
It's...Receivable mission contract.

Spec write what / WHOT

  • Why: background, goal, user value.
  • Where to change: scope, boundaries, clear-cut inaction.
  • What to do: behavior, input output, error and non-variant.
  • How to judge completion: scenes, acceptance criteria and certification methods.

Plan What / HOW

  • Selection of modules, documents and technical options.
  • How to dismantle tasks, sequence and assign responsibilities.
  • How to land, move, roll back and publish.
  • These decisions should be based on the status of the warehouse, not on the death of Spec.
WriteYou can't guess.PutThe decision to find out from the warehouse.Leave it to Agent.
15 / 44Spec-Driven Development
It's tight and easy to maintain.

A good one.
First."What must be true"Write clearly.

# specs/account-deletion.md # Feature: Account deletion ## Intent No valid session is available after the account has been deleted. ## Scope - In: deletion and active sessions - Out: registration and billing history ## Requirement - All active sessions expire immediately after deletion. ## Scenario Given active sessions → When deleted → Then reject ## Acceptance - [ ] Existing sessions cannot authenticate - [ ] Registration flow is unchanged
WHAT:All active sessions must expire immediately.

HOW:AddrevokeSessions()Which Service, which storage, Agent checked the warehouse and then proposed Plan.

Relationship:Spec — Acceptance Triteria — Tests. Test is an enforceable validation, not Spec itself.
16 / 44Spec-Driven Development
Do not write a giant SPEC on a big project.

Dismantling complex targets.Phases, local documents and verifiable results.

01IntentWhy?
02SpecifyWrite the contract.
03ClarifyResolution of differences
04PlanDecide what to do.
05TasksOther Organiser
06ImplementPhased realization
07ValidateContract acceptance
project/ ├── AGENTS.md ├── specs/ │ ├── product.md │ ├── architecture.md │ ├── auth/ │ │ └── auth.md │ └── billing/ │ ├── billing.md │ └── invoice.md └── src/ ├── auth/ └── billing/
  • AGENTS.md(a) Project-level rules;product.mdandarchitecture.mdSet a stable global context.
  • Field Spec placesspecs/auth/,specs/billing/Close to the corresponding operational boundaries.
  • Agent loads only the documents required in the current phase and field at a time to avoid a huge context.
  • Large-scale reorganisation cuts the border first and then removes the batch; no complete system is modified at once.
17 / 44Spec-Driven Development
Let Agent push by stage, not one-off.

Use/goalTurn Spec into a state-of-the-art implementation cycle.

# Example: Give goal, scope and authentication together /goal /goal Read specs/checkout/ Press Phase 1 → Phase 3 for execution Each: Plan Implementing Validate Report evidence and residual risks after completion Undefined scope or contract: suspension of questions
  • Assigned entry:Gives Spec files or directories that do not allow Agent to guess its own context.
  • Designation stage:Push one phace at a time and continue after validation.
  • Specified status:At each stage, completed items, evidence, risks and next steps are recorded.
  • Other OrganiserBorders, competencies, data contracts are not clear, and no unauthorized expansion is permitted.
/goal is not a magic command to replace Spec; it's worth givingObjective, phase, certification and cessation conditionsContinuously visible.
18 / 44Agent Loop / New Functional Development
Turning a delivery into a visible overlap Sub.

The new function is not "one generation at a time."
It's...Target-driven action loops.

01 / GOALClear objectivesRead Spec, confirm scope, acceptance and cessation conditions.
02 / EXPLOREExplore the warehouse.Search symbols, dependencies and existing tests, only relevant context.
03 / PLANPresentation of plansDismantling into small steps allows for the identification of high-risk decisions.
04 / IMPLEMENTExecute ChangesEdits the code by stage, and each change is held back.
05 / VERIFYValidation of evidenceRun tests, check diff against Acceptance Criteria.
06 / NEXTCompleted or continuedThe fulfilment of the conditions ceases; the failure leads to the next round with evidence.
Core:Each round answers "what is the current state, why is the next step, and what evidence can stop".
19 / 44Agent loop / One-time
So that every step can be reset.

Take the example of "order export":
Agent, pass.Evidence, decision-making, validationPush.

# iteration 03: implement export endpoint goal: add order export state: API contract clarified read: orders/service.ts, orders.test.ts plan: add CSV serializer + endpoint test edit: 2 files changed run: npm test -- orders evidence: 18 passed, diff reviewed decision: continue → add permission case
  • Entry:Spec has defined the criteria for input, output, permission and acceptance.
  • Actions:Searches for symbols and tests without reading the entire warehouse.
  • Feedback:The result of the tool is to retain only evidence of failure, difference and the next step.
  • Stop:Functional acceptance is passed or suspended in case of contract, authority, data risk.
INPUTObjectives and contextSpec + Current Status
ACTIONTools and ChangesOne little step.
FEEDBACKResults and evidenceTest / diff/ log
DECISIONContinue or stopBoundary compliance
20 / 44Token Engineering
First, check the ledger, then improve the sentence.

Token costs more than just Prompt.
More fromRepeats the number of context x Agent loops.

Input tokens

System directives, historical dialogues, tools Schema, codes, RAG results.

Duplicate = hidden cost
Output tokens

Answers, reasoning, tool parameters and retesting after failure.

max_output_tokens
Number of calls

Are there really four calls required for classification, extraction, summary, formatting?

Less cycle, less try again.
Total cost ≈ input tokens × input price + output tokens × output price × number of calls
Priority:Prompt caching → context compaction → tool filtering → model routing → loop / call reduction.
21 / 44Token Engineering / Coding Agent
You can't control all the loops. You can control the contents of the context.

Codex / Claude Code:Compress the tool output first.

Location of RTK

Agent runs shell command
    ↓ hook rewrites
RTK executes the real CLI
    ↓ filter / summarize / dedupe
compact output
    ↓
LLM context

It does not change the model, only changes the shape of Shell output into context: individual Rust binary, 100+ command, low cost.

Why is it shorter?

Smart filtering:Remove comments, blanks, templates and progress noise.

Grouping:By file, directory, rule or error type.

Truncation:Keep key context and repeat long lines.

Deduplication:Duplicate logs fold into one article and attach the number of times they occur; the tests usually keep only failed entries.

The border is clear:RRTK officially claims to reduce by up to 90% the Bash output, but this does not amount to a 90% reduction in the bill. It controls only one source of input token;rtk gainUsebytes / 4Token, the percentage is meaningful and the absolute value is not a supplier bill.Official warehouse
22 / 44Token Engineering / Own Agent
Agent controls the entire cycle.

Upgrade the RTK mind toToken-aware Tool Middleware.

01 / TOOL OUTPUTCompression resultTuncate, Sumarize, Deduplicate, return only information useful for the next step.
02 / CONTEXTEvidence as requiredRAG top 3-5, summarizes old history, cache stable prefixes and results.
03 / SCHEMAFilter ToolBy task exposure tool group, reduce irrelevant Schema and wrong calls.
04 / MODELTask routeSimple classification uses small models, complex planning and coding uses strong models.
05 / LOOPControl CycleParallel call, limit retry, set max turns and specify termination conditions.
Tool → raw result → token optimizer → diff / cache / structured extraction → agent context
The difference between the two scenarios:Codex / Claude Code mainly returns fewer tools; self-build Agent can also decide "when, what, how many times, when to stop."
23 / 44LLM Observability
Observe Agent to explain why it's acting like this.

Runtime,Instrumentation,Evaluation
Three different floors.Duties.

Problem / LayerClaude CodeCodexAutoGenLangChain / LangGraph
Persistent instructionsCLAUDE.mdAGENTS.mdSystem messages / agent configPrompts / system messages
Reusable workflowsSkillsSkills / instructionsAgent / workflow / componentTools + prompts / LangGraph nodes
Agent routingSkill descriptionsInstructions + scopeRouter agent / workflow logicConditional edges / router
TracingOpenTelemetry + telemetryLess publicly exposedEvents / callbacks / OTelLangSmith Tracing
Loop controlmaxTurns + runtime limitsRuntime limitsmax turns + terminationrecursion limit + state control
EvaluationExternal eval toolingExternal eval toolingCustom evaluatorLangSmith Evaluations
GuardrailsHooks + permissions + sandboxSandbox + approvalsTool guards / middlewareMiddleware / guard nodes
Cost / tokensTelemetry / usageUsage reportingInstrument LLM callsLangSmith token tracking
Key division of labour:LangGraph control process, LangSmith observation and assessment; AutoGen can also access LangSmith / OpenTelemetry.
24 / 44LLM Observability / AutoGen
Runtme and AgentOps can be decomposed

AutoGen runs,
LangSmith / OpenTelemetry sees the running.

# AutoGen runtime Your Application ↓ AutoGen Runtime │ ┌────┼────┐ ▼ ▼ ▼ Agent Tool Workflow │ events ▼ OpenTelemetry ──→ LangSmith
  • Agent / Tool:Record message, description, parameters, results, errors and time-consuming.
  • LLM:Records model, input/output tokens, latency and cost.
  • Trace tree:Linking LLM, Tool, Hook, Subagent in a run.
Agent Runtime ≠ Observability ≠ Evaluation
AutoGen / LangGraph / Custom → OpenTelemetry → LangSmith / Phoenix → Trace → Eval
ActOps:The self-build system should prioritize the definition of events and trace transactions, and select LangSmith, Phoenix or other backends.
25 / 44LLM Observability / Quality Loop
Tracking is not the end. Production quality needs to be closed.

Trace found mode,Evaluation proves the problem.
Guardrail prevents recurrence.

Skill Selection AccuracyDoes the selected Skill/Agent really fit the task?
Skill Repetition RateIs the same capability meaningfully duplicated?
Skill ChurnA B B A B B for unstable roads?
Agent Loop LengthHow many rounds and tools have been used to complete a goal?
Unnecessary CallsWhich tools/skills calls have not changed the next decision?
Successful TerminationIs it done in accordance with acceptance standards, and not out of compliance with the ceiling?
Trace: revenue-analysis → data-cleansing → revenue-analysis → data-cleansing
Evaluation: unnecessary repetition
Guardrail: max_same_skill_calls = 2
Skill redesign: add explicit exit condition
Regression: task X ≤ 5 skill invocations
Production closed rings
Tracing → Evaluation → Guardrail → Skill redesign → Regression test

Let's not just record what happened, but also document Agent why he chose, why he continued, why he stopped.
26 / 44Autonomous boundaries
Business really has to decide.

It's not "AI can do it."
It's "what step do we allow it to make?"

Development environment

Freer.

Read the code, change the code, run the test. Allows rapid error.

Test Environment

Executable

Specifies the directory to write, specifies the command to run, and the key results need to be confirmed.

Production environment

Read-only priority

Read the log, check the data, make recommendations. The responsibility for hazardous operations and eventual liability rests with the person.

All manualPeople do it, AI. Look.
AI RecommendationPeople decide.
AI ImplementationConfirmed
Critical steps for trialAutomation within borders
Full AutoOnly for low-risk scenarios
27 / 44From Prompt Engineering to Graph Engineering
The next stage is not learning more terms.

LLMs are getting better at understanding, acting, and collaborating.
Our work is moving from “writing prompts” to “designing systems.”

Timeline from prompt engineering to context engineering and harness engineering as agent complexity grows
As models improve, the engineering surface moves upward.
01 / Prompt Engineering

Tell him what to do.

Write more clearly.

LLM: Follow instructions
02 / Context Engineering

Let him know where to do it.

Projects, rules, information in context.

LLM: Using context
03 / Spec Engineering

Define what's done.

Input, output, boundary, acceptance and observation.

LLM: Dismantling task
04 / Goal + Loop Engineering

To target. Allow it to overlap.

One step, one result and one next.

LLM: Planning and Calling Tool
05 / Harness Engineering

Give it the fence to run.

Tests, privileges, tools and feedback are fixed.

LLM: Implementation within Borders
06 / Graph Engineering

Design taskchart

Let's get multiple steps, Agent and people working together.

LLM: Coordination of complex systems
Each move up happens when the previous layer becomes the bottleneck: better prompts become context, context becomes specifications, and specifications become a system with feedback.
28 / 44Change in capacity and focus
From Write Prompt to Design Operating Environment

ILM's ability has risen.
The developers are no longer solely responsible for "output text".

Phase
LLM Capacity Change
Our focus / working methods
Prompt Engineering

From the understanding of a directive to the stable adherence to format and tone.

Practice to express tasks, check output, and repeatedly rewrite hints.

Context Engineering

Project information, rules and historical information can be put into judgement.

Collapse the context and maintain README, AGENTS.md, knowledge boundaries.

Spec Engineering

Natural language targets can be broken down into steps, constraints and outcomes.

Defines input, output, anomaly and acceptance before AI executes.

Goal / Loop Engineering

Can plan, call tools, observe results, fix paths.

Change from "writing once" to "management feedback loop" to focus on evidence and state.

Harness Engineering

The task can be accomplished in the context of testing, authority and tool constraints.

Design operating environment: tests, privileges, tools, rollbacks and human hearings.

Graph Engineering

It can coordinate multiple Agent, workflow and dependency relationships.

Design task maps, nodal responsibility, handover, Eval and system-level feedback.

LLM change:From answering questions to fulfilling objectives in context and constraints.

Human changes:From doing every step in person to designing objectives, boundaries, feedback and collaborative maps.

29 / 44Three product development feedback cycles
Three product development feedback loops: Agency Working Loop, Development Feedback Loop, Extranal Feedback Loop

The greater the cycle, the slower the feedback, but the closer it is to the real product: the minute level of execution, the hourly calibration, the gradation.

30 / 44From tool to work stream
Next job starts.

Don't learn first.
First let AI do a real job for you.

01

Pick a task.

HF, repeat, results judged.

02

To the border.

Define directories, commands, environments.

03

Run validation

Test, log, manual acceptance.

04

Skill

Turning the method into a reuseable process.

05

Continuous improvement

With real feedback.

31 / 44LLM hallucinations: causes and solutions
It doesn't make sense. It doesn't make it right.

LLM will "false" not because it wants to lie.
It's the generation of gills to verify.

Why did that happen?

Probability generation

The model gives priority to the generation of text like an answer, which is not automatically endorsed as a fact.

Context Missing

Without business rules, real data or up-to-date information, reliance is placed on existing models.

Border Fuzzy

Too many problems, incomplete input, unclear acceptance, and models can easily complete information that does not exist.

How to write a Skill

Give it the basis.

Access to documents, databases, tools and traceable sources does not allow them to respond in a vacuum.

Make it acceptable.

Requires reference, structured output, testing, rule-checking and evidence of failure.

Reservations

Facts, figures, competencies, legal, financial and operational rules are not directly outsourced.

High-risk judgements cannot simply ask "like or not answer" but:On what basis? How to write a Skill Who's responsible?
32 / 44RAG: Access to knowledge
Let the answer be justified, let the action have context.

Evolution of RAG:From one search to Agent, take evidence and act as required.

RAG 3rd floor structure: Naive RAG, Retrieva Layer, Agenic Layer
The key to business landing: freshness of data, traceability of sources, authority and acceptance.Reference RAG Architecture
33 / 44RAG: Distillation Layer
RAG quality is decided before retrieval

Fix the unit of knowledge
before tuning the vector stack.

Naive RAG pipeline compared with a RAG pipeline with a distillation layer Seven-stage real-world RAG pipeline from ingest through export
A distillation layer turns documents into smaller, cleaner, governed question-answer units before vectorization.
  • The chunk is the hidden assumption. Token-based chunks have no idea boundary, version context, or access state, so retrieval can return incomplete or conflicting evidence.
  • Use a question-answer packet. One validated claim plus typed governance fields makes the indexed unit match the way users actually ask questions.
  • Distill before vectorization. In the supplied benchmark, semantic deduplication cut the corpus by up to 40x, reduced query tokens by 3x, and improved retrieval distance by about 2.3x.
  • Make governance part of the data. Version state, clearance, privacy, and source metadata travel with each block instead of living as fragile orchestrator logic.
  • Seven stages make failures localizable. Scope, ingest, extract, deduplicate, auto-tag, validate with SMEs, then export to the vector store.
The practical rule: clean and structure the knowledge unit upstream; keep retrieval, reranking, and embeddings focused on matching it.
34 / 44LLM Selection
The stronger the model, the better.

Picking models, not looking for the strongest.
It's looking for the best value for money.

Codex Radar: relative cost of different models versus IQ
Codex Radar: The cross-axis is the relative aggregate cost and the vertical axis is IQ. The chart is suitable for relative position, not a single absolute list.
Tasks

Complex Debug, Structure, Spec: Prioritize reasoning and code understanding.

HF missions

Logging, summary, simple revision: speed and cost are more important.

Real benchmarks

Compare code, context, tool call, speed and cost with your tasks.

35 / 44Agentic Design Patterns / Decision Tree
Pattern selection starts with the task

Pick the pattern from task properties.
Do not start with the architecture.

Decision tree for choosing an agentic design pattern
Decision-tree approach to choosing an agentic design pattern.
  • 1. Start with the path. If the solution is known and deterministic, use a sequential workflow; use the model only where interpretation or generation is needed.
  • 2. Add capability as needed. For open-ended work, tools and external information provide access to APIs, databases, documents, and system actions.
  • 3. Separate planning from exploration. Use Planning when stages and dependencies are clear; use ReAct when structure emerges through execution.
  • 4. Spend for quality deliberately. Add Reflection when quality criteria are explicit and the cost of errors justifies extra latency.
  • 5. Scale only for a real bottleneck. Use Multi-Agent for specialization or scale; otherwise, a single agent is usually enough.
Patterns are starting points. Re-evaluate them as feedback, constraints, and failure signals accumulate.Source article
36 / 44Agentic Design Patterns / Framework
A pattern is a composition of capability and execution shape

Use two lenses to place the pattern:
what the agent does and how work moves.

Agent Design Pattern Framework mapping cognitive function to execution topology
Agent Design Pattern Framework: cognitive function x execution topology.
  • Cognitive function is the vertical lens. Perception, memory, reasoning, action, reflection, collaboration, and governance describe the work being performed.
  • Execution topology is the horizontal lens. Chain, route, parallel, loop, hierarchy, and orchestration describe how work and control flow.
  • Patterns are composable primitives. Examples include RAG Pipeline, Tool Dispatch, Plan-and-Execute, Fan-Out / Gather, and Hierarchical Delegation.
  • Cross-cutting planes keep the system operable. Observability, Evaluation & Validation, and Security & Identity apply across the matrix.
  • Design implication: locate the needed capability and topology first, then combine the smallest set of patterns that solves the task.
The tree chooses; the matrix composes.
37 / 44Tool selection for domestic developers
Different environments allow for consistent working methods

We can't use an overseas tool in a stable way.
Not the same as not starting AI Coding.

Artificial Analysis Information Index: Model capabilities and cost distribution
Artificial Analysis Inteligence Index: Using the distribution of capabilities and costs to establish a selection baseline.
Coding Agent
Trae, WorkBuddy, Qwen Code, and Ideas.
Model / API
Select the "sufficient" model by code, reasoning, context, speed and cost.
Model route
Multiple models are connected to the same work environment using CC Switch or similar routes.
Focus
Do not bind a brand; keep mandates, privileges, tests and acceptances stable.

Model ranking is input, not decision-making. Run Benchmark on a real mission, then decide on the mix of tools.

38 / 44High
High content 01

Let's see.Thinking, acting, correcting..

ReAct

Planning: low / hidden self-adaptation:★★★★★
[Task]
  |
[Thought] -> [Action]
                 |
           [Observation]
                 |
              [Thought]
                 |
              [Action]

Open task, search, tool call, trouble check.

Reflection / Self-Critique

Planning: Adaptation:★★★★★
[Draft / Run]
      |
  [Evaluate]
    /     \
[Pass]  [Improve]
  |        |
[Done] <---+

After implementation, they are self-assessed and improved and suitable for coding, writing, data analysis.

Tree of Thoughts

Planning: Self-adaptation:★★★★☆
[Problem]
    |
+---+---+
|   |   |
[A] [B] [C]
 \   |   /
  [Evaluate]
      |
 [Best path]

At the same time, multiple options are explored to assess and choose the best path.

Cycle-based Agent differences: Feedback occurs within a mission.29
39 / 44High Agent Mode / Shape
High content 02

Look at Agent. How about that?Disassembly tasks, roles, organizational status.

Plan-and-Execute

Planning: Self-adaptation:★★★★☆
[Goal]
  |
[Plan]
  |
+---+---+
|   |   |
[S1][S2][S3]
 \   |   /
 [Replan?]

Targeted multi-step tasks are planned and then implemented and reprogrammed as necessary.

Graph / Workflow Agent

Planning: Remarkable self-adaptation:★★★☆☆
[State]
   |
[Node A] --> [Node B] --yes--> [Node C]
   |              |
   +----- no -----+
                  |
              [Human]

Enterprise processes, firm business rules, status and branches can be tracked.

Multi-Agent

Planning: Distributional self-adaptation:★★★★☆
            [Manager]
           /    |    \
        [Agent A][Agent B][Agent C]
           \    |    /
          [Shared result]
                |
             [Deliver]

The different professional competencies work in parallel, suited to the division of roles and complex delivery.

Discrepancies in layout Agent: turn one answer into a manageable task system.30
40 / 44AI Age Developer Capacity
The stronger AI, the more people's scarce value is judged.

CodeIt's going to get cheaper.
But...DecisionIt'll be more expensive.

01 / Demand modelling (link to physics world)

Turning realistic targets into enforceable compacts

Clarify real operations, user scenarios, scope and acceptance conditions. The more ambiguous you enter, the easier it is for Agent to quickly magnify the wrong direction.

02 / Structure discretion

Reduce the optional space with constraints

The principles of modular boundaries, data non-variant and architecture are written into rules that Agent can implement, and the long-term experience is deposited as reusable constraints.

03 / Quality responsibilities (link to physics world)

Use the evidence to protect the real consequences.

Tests, reviews, issuance of door closures, online observations and user feedback form the chain of evidence. The code can be generated by AI, and quality risks still need to be borne by people.

Inputs are allocated by risk:Standardized, low-risk small team projects can be less structured; complex systems, key data and long-term evolution still require clear constraints. AI will take over a growing number of structures, but will not automatically bear the consequences for you.
41 / 44Multi-Agent / Distributed Systems
Don't make a lot of Agent just talk in groups.

How do you communicate with each other?
Think of it as a first.Distribution systems.

# task and message flow User Goal │ ▼ [Router / Manager] ┌─┼──────────┐ ▼ ▼ ▼ Planner Researcher Coder └────┬─────┘ ▼ [State / Event Log] ▼ [Reviewer] pass / retry / stop
  • Message contract:task_id,sender,recipient,type,payload,evidence.
  • State ownership:One Agent is responsible for writing, other Agent submits proposals or read-only.
  • Failed boundary:Timeout, retrying, repeating messages, back pressure and permissions are handled visibly.
  • Termination and observation:Defines the DONE condition and records news, decision making, tools, Token.
Communication modeStructureIt suits the scene.Main risks
Point-to-PointAgent A → Agent BClear mission handoverConvergence, single-point dependency
Broadcast / Group ChatOne message, poignant.Share context, multiple reviewContext expands, repeats responses
Broker / Event BusAgent → Broker → AgentEvent-driven, step-by-step collaborationMessage sequence, double consumption
Shared StateAgent ↔ State StoreLong process, recoverable tasksState competition, confusion.
Criteria for judgement:It's up to you to decide who can see the news, who can change the state, who has the right to continue, and who can expand the communication.
42 / 44Multi-Agent / AutoGen
Runtme manages participants, routers and termination conditions together

AutoGen: Turn Agent collaboration intoManageable news systems.

# AutoGen: message-oriented team Task │ ▼ [Team / Manager] ┌──┼─────────┐ ▼ ▼ ▼ Planner Researcher Reviewer └──┬────┘ ▼ Runtime topics + tools ▼ termination condition
  • Participants:UseAssistantAgentExpressing different roles, receiving assignments or exporting evidence as required.
  • Message route:Team / Manager sends the message to the participants; participants share the necessary context but do not share all internal status.
  • Tool boundary:Pass.FunctionTool,AgentToolor MCP exposure capability, tools still need control over privileges, time overruns and thorium.
  • Conditions for discontinuation:TerminationCondition, maximum rotation and manual intervention to prevent unlimited collaboration.
message = { task_id, sender, recipient, type, payload, evidence, created_at }
trace = run → participant message → tool call → result → next decision → termination
Distribution map:Agent is the service character, Team / Manager is the route layer, Runtime topic is the message address, terminisation is the system suspension condition.AutoGen official warehouse
AutoGen is currently in maintenance mode; this is an example of multiAgent Runtme, and the new project should also be evaluated.
43 / 44Multi-Agent / LangChain
Translating messages into state changes and conditions Side

LangChain / LangGraph:
UseStatus ChartExpress how Agent continues, branches and ends.

# LangGraph: state-oriented workflow START │ ▼ [Planner] ── conditional ──┐ ├──→ [Researcher] ────────┤ └──→ [Coder] ─────────────┘ │ ▼ [Reviewer] / \ pass fail │ │ END ───→ Coder
  • State:Sharegoal,evidence,draft,review,attempts, each update can be tracked.
  • Node:Each node can be an Agent, a tool or a certainty function, enter a state and return a local update.
  • Conditional edge:Select the following section according to status, moving the router rule from hidden conversations to visible control streams.
  • Observation and assessment:@toolResponsible for capacity, LangSmith for track, dataset and assessment, operating at the same time as observations.
Design LayerAutoGenLangChain / LangGraphDistribution system considerations
AgentAssistantAgentAgent / graph nodeBoundary between service roles and duties
CommunicationTeam publish / manager routeState update / graph edgeRadio, straight line or event?
State + terminationRuntime / team state + conditionStateGraph state + ENDSingle author, budget, recovery
Tools + observabilityFunctionTool / events / callbacks@tool / LangSmith tracingPermissions, trace, metrics, eval
OrganisationAutoGen is easier to show "how news flows", and LangGraph is easier to write "how the state changes and why it happens next." Both require a contract of information, state ownership, failure and termination conditions.
44 / 44Take three sentences.
End

It's not necessarily a substitute for developers.
But it will redefine what developers do every day.

First let AI do a real job for you.
And teach it experience, SOP and context.
Make it as automated as possible within the right borders.
01 / Real Job

Prioritize Coding Agent, let AI do a real job for you.

02 / Context

Teach AI about projects, experiences, SOPs and working methods.

03 / Boundary

Clear lines of authority, testing, acceptance and what cannot be directly outsourced.

04 / Automation

In the right boundary, make AI as automated and as feedback as possible.

ObjectiveContextBorderValidation