Node Deep Dive / Agentic

Agentic Engineering in Practice: Modular, Outcome‑Driven, Continuously Evolving

This post breaks Agent development down into three main tracks — modular design, outcome‑driven delivery, and continuous evolution — and maps them to concrete components and practices.

2026-02-01~ 12 min read
#node/agentic #agentic #LLM #Prompt

Borrowing from software engineering experience, you can push Agent applications along three dimensions:

  • Modularity: standardized responsibilities, single responsibility, higher reusability
  • Outcome‑driven: testable, verifiable, regression‑friendly
  • Continuous evolution: iterative optimization, feedback loops, versioning

Modularity

Prompt ≈ Code
Model ≈ Compiler
Agent ≈ Application

At a first approximation, you can treat prompts as a new kind of high‑level programming language. It has much higher abstraction power and expressiveness, but also brings new challenges:

  • Uncertainty: model outputs are stochastic and diverse; it is hard to guarantee consistency and predictability.
  • Opacity: the internal mechanisms and decision process of models are black‑box; they are hard to understand and debug.
  • Dependency: performance and behavior depend on training data and architecture; they are hard to control and optimize.
  • Safety: models may emit harmful, biased, or inappropriate content; they are hard to guard and govern.

Likewise, you can see an Agent as a new application architecture with higher intelligence and autonomy.

Core Components of an Agent

System Instruction

Defines global rules, roles, and safety boundaries; always in effect.

  • Similar to: environment variables or global configuration
  • Examples: SOUL.md, AGENT.md, CLAUDE.md

Command

Executable commands explicitly triggered by the user.

  • Similar to: API endpoints or CLI commands
  • Examples: "help me write an email", /search AI safety papers

Skill

Capabilities the Agent can autonomously invoke.

  • Similar to: dynamic dispatch based on conditions
  • Examples: pdf‑convert, code‑execution, web‑search

Context and Data Layer

Memory

Cross‑session state and preferences, ensuring continuity.

  • Similar to: database or cache
  • Examples: user profile memory, task state memory

MCP (Model Context Protocol)

External capability integration; provides data and interfaces for Skills and Memory.

  • Similar to: third‑party APIs
  • Examples: GitHub MCP, Google Search MCP

Packaging and Orchestration

By combining the above layers into a minimal deliverable intelligent unit, you can version, permission, test, and iterate Agents just like traditional software.

Single Agent

Bundle the layers into a minimal shippable Agent.

  • Similar to: software package or service
  • Examples: Email Assistant Agent, Research Assistant Agent

Multi‑Agent

Multiple Agents collaborate through scheduling/orchestration or autonomous coordination to complete complex tasks.

  • Similar to: microservices architecture
  • Examples: customer support system with email, chat, and knowledge‑base Agents
mermaid
flowchart TD
  subgraph CA[Agent]
    SI[System Instruction]
    MS[Command]
    AS[Skill]
    MCP[MCP]
    M[Memory]
  end

  U('User') --> CA
  SI --> MS
  SI --> AS
  MCP --> MS
  MCP --> AS
  M[Memory] --> MCP

  CA --> Prompt
  Prompt --> LLM

Reference: Awesome Agentic Patterns

Outcome‑Driven

Why Outcome‑Driven Matters

LLMs are inherently uncertain and black‑box; trial‑and‑error is not a smell but the normal path. That means every module must satisfy:

  • Testable: you can verify that functionality works.
  • Reproducible: results have some degree of consistency.
  • Checkable: you can evaluate output quality.
  • Regressable: you can roll back versions and trace issues.

Design and development should start from acceptance criteria and validation paths, then implement capability orchestration. If something is not testable, it is not fit for production.

From "Code" to "Outcome"

If you treat prompts as a programming language, then what Agents generate are analogous to compiled artifacts in software engineering (like .class files). Most of the time, you do not need to stare at them; you should focus on outcomes — whether user goals are achieved and value is created. Obsessing over every detail of the "code" leads to micromanagement and kills leverage and innovation.

"Insist on not looking at any code other than CLAUDE.md. Eliminate micromanagement of AI. Using AI is an excellent way to practice servant leadership as a leader." — Yuanming Hu · "I Work for 10 Claude Code Agents"

Guard the Architecture, Let Go of the Code

This is the higher‑leverage way to work:

  • Focus on outcomes and value, not line‑by‑line code control.
  • Constrain the system with boundaries and acceptance criteria, not micromanage execution.
  • Spend your attention on architecture, prioritization, and feedback loops — the high‑leverage decisions.

Continuous Evolution

Why Evolution Is Necessary

An Agent should be a continuously evolving system, not a one‑off deliverable. You keep improving its capability and adaptability by:

  • Iterative optimization: refine based on real usage feedback.
  • Feedback loops: deliberately collect and apply user feedback.
  • Version management: support canary releases, A/B tests, and fast rollback.

Design Principles

You need to plan for long‑term maintainability from day one:

  • Maintainability: clear module boundaries and documentation.
  • Extensibility: reserve extension points and integration hooks for new capabilities.
  • Upgradability: avoid tech debt and over‑coupling.

Personal Practice

GitHub Copilot

With Customize AI in Visual Studio Code, Copilot already supports most Agentic techniques, including:

  • .github/copilot-instructions.md = System Instruction
  • .github/prompts/*.prompt.md = Command
  • .github/skills/*/SKILL.md = Skill
  • MCP & Custom Agents

Without changing the development environment, you can gradually build Agentic workflows via custom instructions, and eventually replace most repetitive work. For example: /test-golang, /code-review, /debug-kubernetes, /get-my-jira-tickets

Memory

Memory stores user preferences, history, and context so that interactions across sessions stay coherent. Implementation options include:

  • File system: store memory in files under a specific path; pass the path as input.
  • File system + Skills: provide skills for reading/writing memory without exposing concrete paths (e.g. OpenSpec).
  • MCP: store memory in an external system (database) and access it via MCP (e.g. OpenMemory).

🤖 Suggested prompts for AI:

  • "Difference between Commands and Skills"
  • "Versioning and rollback strategies for Agents"
  • "How to test and evaluate Agent output quality"