From DingTalk Queries to Code Delivery: Building a Team-Level Agent Infrastructure with Domino

Background: Domino's Evolution

Domino originated as an internal frontend source-code positioning tool and gradually expanded to cover requirement understanding, coding, review, deployment, and acceptance. The initial phase solved the core problem: how to let a CodingAgent complete a task in real repositories and real R&D pipelines. This phase built isolated sandboxes, single-app tasks, Flow multi-app pipelines, CodeReview, O2/AoneCD deployment, and AI page verification, enabling Agent to push code through the actual R&D process.

Emerging Problems in Daily Use

Users ask questions directly in DingTalk groups, not by opening an AI platform first.

Many R&D questions don't require immediate sandbox creation; they may only need historical decisions, release-process confirmation, or existing logic location.

After a task ends, the Agent's acquired business context and team conclusions sink with the session, forcing re-explanation next time.

Generic CodingAgents read/write code but don't understand console-project engineering norms, i18n pipelines, login methods, design-spec structures, or release-verification methods.

If unresolved, the Agent remains a "high-level tool requiring human operation" rather than a daily collaboration partner.

Solution: A Layered Agent System

Domino's latest evolution answers three questions with a layered architecture:

How does Agent naturally enter the team's existing collaboration entry point? → ConsoleAgent as a persistent DingTalk group resident.

How do contexts from different groups/sessions become reusable organizational knowledge? → Three-layer context: group Session, KBase space memory, knowledge base & CodeWiki.

How does a generic model master professional frontend console R&D methods? → Domain-specific SKILLs (engineering methods as executable assets).

Two-Agent Relay: ConsoleAgent + SandboxAgent

The system splits "understanding & routing" and "execution & delivery" into two roles with different lifecycles:

@Bot in DingTalk group
        │
        ▼
ConsoleAgent (long-term entry)
        │
        ├── Group context  ──▶ continue current discussion
        ├── KBase memory   ─▶ retrieve cross-group/session team conventions & decisions
        ├── Knowledge base ─────▶ query product, process, architecture knowledge
        ├── CodeWiki ───▶ query code implementation facts
        ├── Direct Q&A
        │
        └── Need real repo or code changes
                │
                ▼
        Create single-app task / Flow
                │
                ▼
SandboxAgent (task execution)
        │
Read code → Modify code → Verify → CodeReview → Deploy → AI page verification

Benefits: Lightweight Q&A no longer spins up expensive sandboxes; all code changes occur in isolated, traceable, verifiable R&D environments.

Three-Layer Context Architecture

Layer 1: Group-Level Session (Local Context)

Each DingTalk group maintains an independent conversationId, sessionId, and message history. Follow-up questions naturally continue (e.g., "Why did this change fail?" → "Which pre-release version should I check?"). Sessions are isolated across groups to avoid cross-contamination. Persistence is semantic: even if underlying instances switch, the Agent restores the session.

Layer 2: KBase Space Memory (Cross-Group/Session History)

Decoupled from any single conversation, KBase stores refined team decisions and conventions for long-term reuse. Suitable content includes:

Confirmed technical decisions and trade-off rationales.

Long-lived directory, module, and ownership information.

Special environment constraints, joint-debugging methods, and troubleshooting conclusions.

Engineering norms and operational conventions formed through repeated collaboration.

Updates/deletions target specific memory entries; goal is accumulated facts/decisions, not raw chat logs.

Layer 3: Knowledge Base & CodeWiki (Formal Fact Sources)

ConsoleAgent routes queries by type:

Product knowledge, engineering norms, deployment processes, architecture → team knowledge base.

Implementation logic, interface definitions, code structure → CodeWiki and code platform.

Chinese UI copy not directly searchable in source → i18n reverse-lookup SKILL to find key, then locate call sites.

After multiple retrievals fail → delegate to SandboxAgent for real-repo investigation.

This layered approach lets the Agent distinguish current dialogue, historical experience, and formal facts — not just stuffing more context into the model.

SKILL: Turning Frontend Engineering Experience into Executable Methods

Generic models know React/TypeScript but lack team-specific tacit knowledge: framework identification, request wrapping, copy locations, sandbox login state, design-to-component mapping, pre-release verification. Domino codifies stable, reusable parts as built-in SKILLs. Each SKILL defines trigger conditions, execution steps, tool selection, and acceptance criteria — loaded only when the scenario matches, avoiding prompt bloat.

Key SKILLs

mq-frontend-skill

: Entry point for messaging console frontend; routes to sub-skills xconsole (RocketMQ, EventBridge, KafkaNext) and recore (MNS, AMQP, MQTT, Kafka). Encodes TypeScript, component reuse, request wrapping, styling, i18n, validation constraints. find-i18n-key: Reverse-lookup i18n key from Chinese copy, then locate call sites in code platform or real repo — turns "user-visible language" into "code coordinates". frontend-sandbox-auth: Solves sandbox page login & API permission issues (Cookie, sec_token, proxy, launch params); distinguishes code defects from environment auth problems. medusa: Manages multi-language copy query, write, batch update, translation, audit, publish — brings i18n changes into the same Agent workflow. mgdone-dsl-analyze: Via MasterGo MCP, fetches design DSL, analyzes component hierarchy/layout/style data, archives raw design info — upgrades design input from visual reference to structured, traceable context. ai-testing: Generates AI Testing instructions (E2E, smoke, regression) against pre-release console, tracks results, sends DingTalk notifications. Integrated with cloud-native SRE team's SQA platform; verifies both incremental changes and existing functionality.

Clarification Before Execution: /brainstorming

Used to clarify goals, constraints, and acceptance criteria before complex implementation. Embodies the validated judgment: "Many failures aren't because the model can't write code, but because the problem wasn't understood clearly before acting." System prompts at pre/during/post stages are heavily constrained using production problem-solving experience and multi-layer context to ensure execution direction and quality.

SKILL vs CLI/MCP: Division of Labor

SKILL solidifies engineering methods: when to trigger, steps to execute, checks to use, acceptance standards.

CLI/MCP connects real platforms: standardized tool interfaces to access knowledge, code, collaboration, design, and release systems — grounding methods in actual data and operations.

SKILL decides "how to do it"; CLI/MCP decides "what can be accessed". Together they turn team experience into executable, verifiable R&D actions.

End-to-End Workflow Example: "Design Spec → Console Page"

/brainstorming

clarify interactions & acceptance. mgdone-dsl-analyze fetch structured design data via MasterGo MCP. mq-frontend-skill constrain implementation per engineering type. find-i18n-key + medusa handle existing & new copy.

SandboxAgent codes in real repo, runs build/test.

Code enters CodeReview & O2 iteration. ai-testing verifies pre-release page.

Production usability comes from the model's ability to call real systems and follow team-validated methods to close the loop.

Platform Access & Security

OAuth integration with Aone open platform. MCP tool calls reuse the current principal's identity: ConsoleAgent uses its configured auth; delegated tasks make SandboxAgent prefer the real requester's auth. No platform passwords stored server-side; auth expiry yields explicit capability-unavailable feedback, improving cross-platform tool-call security and traceability. Domino currently connects Aone collaboration, code platform, knowledge platform, change release, O2, Yuque, MasterGo via MCP. Capabilities are injected per Agent role, user auth, and tool whitelist — avoiding irrelevant context and unnecessary operation scope.

From a DingTalk Question to Traceable Delivery

Real collaboration flow:

User in business group asks: "Why does instance detail page message backlog differ from monitoring page? If frontend issue, please fix."

ConsoleAgent continues current group Session, checks KBase for historical conclusions, queries knowledge base & CodeWiki for metric definitions & existing implementations.

If knowledge yields answer → replies in-group with citations. If real repo read/reproduction/code change needed → queries registered apps, creates single-app task, posts task link back to DingTalk.

Task creation propagates real asker's employee ID/nickname as requester; subsequent sandbox, MCP auth, task records, dashboard stats attribute to actual user.

SandboxAgent in isolated sandbox: (1) uses frontend project SKILL to identify engineering norms; (2) combines copy reverse-lookup, code search, real runtime to locate issue; (3) modifies code, completes build/test; (4) user confirms result in task chat; (5) shares task record with reviewers or delegates to assistants; (6) via "Task Change Submit" completes Git push, CodeReview, O2 change binding, deployment; (7) AI Testing verifies pre-release page, brings result back into R&D collaboration chain.

Group Q&A and code delivery become a single traceable, handoffable, stat-trackable chain.

Sandbox Work Records: From Personal Session to Team Collaboration

Sandbox is not a one-off black box. Conversations, Agent tool calls, stage progress, code changes, CodeReview, deployment status, and page verification results persist in Console, forming a reviewable, shareable, continuable work record.

This changes collaboration: shared artifact is full R&D context, not just a final link or code snippet. For console requirements, context sharing is critical — implementers no longer stitch together requirement descriptions, page phenomena, call chains, related code, test accounts, verification results; task record delivers all at once, letting implementers jump straight to diagnosis and solution. Cross-role communication cost drops significantly; delivery rhythm stays continuous.

Shareable: via task/chat links reviewers see requirements, process, current state; read-only view safe without sandbox access.

Handoffable: owner designates assistant with current context, test accounts, deadline, next steps; assistant continues in same task.

Traceable: every input, Agent reply, tool result, stage state stays in one record for retrospectives.

Bounded multi-party collaboration: creator, real requester, designated assistants, admins have distinct read/write permissions; execution rights per session isolated by request to prevent accidental interruption.

Current collaboration centers on owner/asker + designated assistants, but underlying record/permission model elevates Agent tasks from "personal drafts" to team-readable, handoffable, verifiable R&D spaces.

Post-Launch Metrics (July 1–31)

135 code tasks initiated

127 in-group business Q&A completed

20+ active teams

Covers 60%+ of daily task Q&A and legacy page development work

Five Key Insights

Agent must enter work, not force work to migrate to Agent. DingTalk is where problems naturally occur; only by entering existing entry points can Agent cover the high-volume questions users won't create formal tasks for.

More context isn't always better; layering beats stacking. Group Session, space memory, knowledge base, code facts have different trust levels and lifecycles. Mixing them into a mega-prompt wastes tokens and blurs fact boundaries. Let Agent retrieve by question and judge by source.

Team experience must graduate from Prompts to maintainable SKILLs. One-off prompts expire fast and are hard to validate. SKILLs version-control trigger conditions, toolchains, and acceptance criteria, enabling domain engineers to maintain them and distribute on-demand to ConsoleAgent and SandboxAgent.

Unattended ≠ no one responsible. ConsoleAgent autonomously retrieves, answers, delegates; SandboxAgent autonomously codes and verifies; but CodeReview, deployment confirmation, final release retain human decision nodes. Goal: free people from repetitive execution, focus attention on business judgment and risk decisions.

Production usability comes from boundaries, not "omnipotence". ConsoleAgent doesn't modify business code directly; SandboxAgent doesn't inherit entire group chat; space memory excludes personal data; MCP injects by auth & whitelist. These boundaries make Agent capabilities safe to place in real R&D workflows.

System Core Module Matrix