“

Topic: AI-Native Engineering | Level: Advanced | Reading Time: 40 minutes

The AI-Native R&D Operating System: From Agent Tools to Organization-Scale Delivery

#TL;DR

AI-native engineering is not about giving every developer a chatbot. It is about redesigning how an organization expresses intent, supplies context, executes work, proves quality, and compounds what it learns. This guide presents a practical R&D operating system built around DDD, specification-driven development, Agents, Skills, Workflows, Context Packs, versioned Artifacts, and repeatable Evaluations.

The central argument is simple: model capability is becoming a commodity. The durable advantage comes from turning organizational knowledge, delivery processes, evidence, and governance into executable protocols.

#1. How to Use This Guide

This is not a conceptual white paper. It is a minimum complete system that a real engineering organization can start, operate, and audit. The company provides a shared foundation; domains and teams tailor it according to business risk.

#At company level

Define the constitution, asset standards, permission model, evaluation policy, platform capabilities, and mandatory quality gates. Maintain the organization-wide registry.

#At domain level

Maintain the ubiquitous language, bounded contexts, business rules, contracts, and evaluation sets for high-value scenarios.

#At team level

Select a pilot value stream, configure Agents and Skills, deliver real work, and feed operational evidence back into the system.

Three constraints apply everywhere:

1. Do not jump directly from chat to code. At minimum, establish the goal, scope, acceptance criteria, and impact analysis.
2. Do not let an Agent certify its own work. Use deterministic tools, an independent reviewer, or a human gate.
3. Do not leave durable knowledge inside conversations. Stable facts return to authoritative documentation, repeatable methods become Skills, and failure modes become evaluation cases.

#2. Goals, Boundaries, and Design Principles

An AI-native R&D system should make delivery more predictable, knowledge reusable, collaboration scalable, and risk governable.

#Eight operating principles

#3. The AI-Native R&D Operating System

The operating system has seven layers. Agents live inside the system; they are not the system itself.

• Governance layer: organizational constitution, risk classification, permissions, responsibility, audit, cost, and asset standards.
• Intent layer: strategy, PRDs, domain models, Specs, contracts, ADRs, and acceptance criteria.
• Execution layer: Agents, Skills, Workflows, human gates, CI/CD, environments, and tool calls.
• Context layer: task routing, retrieval, code intelligence, permission filtering, compression, citation, and context assembly.
• Knowledge and memory layer: authoritative knowledge, episodic records, lessons learned, procedures, cases, and temporal knowledge graphs.
• Evaluation and observability layer: quality, compliance, efficiency, cost, drift, traces, replay, benchmarks, and production feedback.
• Platform integration layer: Git, IDEs, model gateways, MCP and other tools, artifact repositories, developer portals, IAM, and secret systems.

#Core object model

#4. Organization, Accountability, and Governance

The company should build a common foundation, but it should not create a central Agent team that attempts to perform all engineering work. Standards and governance are centralized; domain knowledge and delivery accountability remain close to the teams.

#A three-level organization model

#Minimum RACI

#Risk classification and human gates

#5. Use DDD to Stabilize Meaning and Specs to Stabilize Intent

DDD answers, “How is the business world divided and expressed?” Specification-driven development answers, “What must this change alter, and how will we prove it?” Together they provide facts that an Agent cannot casually reinterpret.

#Minimum domain asset set

• Ubiquitous language: canonical name, display name, definition, examples, forbidden synonyms, and owner.
• Bounded contexts: responsibility, core model, upstream and downstream relationships, integration contracts, and team boundaries.
• Business invariants: conditions no implementation may violate.
• State machines and domain events: states, triggers, guards, events, and their meaning.
• Scenario cases: happy paths, boundaries, exceptions, and counterexamples that become acceptance and evaluation data.

#A practical change model

Current Truth
    + Change Proposal (why change)
    + Spec Delta (what is added, changed, or removed)
    + Design (implementation and trade-offs)
    + Tasks (how work is executed)
    + Evidence (how correctness is proved)
    = New Truth

Greenfield projects can follow Spec → Plan → Tasks → Implement. Existing systems usually benefit from current specification + change delta + post-delivery archive, which avoids rewriting the full body of documentation for every change.

#Specification quality gates

• Completeness: goal, scope, non-goals, actors, primary flows, exceptions, acceptance, dependencies, and risks are present.
• Testability: every requirement can become Given/When/Then or another executable criterion.
• Consistency: terms, interfaces, states, and fields agree with the domain model and authoritative contract.
• Traceability: requirements, design, tasks, code, tests, and release evidence share identifiers.

#6. The Organizational Intelligence Asset Catalog

A prompt is a transient expression. The assets worth governing can be reused across people, projects, and models and can be evaluated independently.

#Registry structure

ai-native-registry/
├─ policies/          # organizational and domain rules
├─ agents/            # role definitions and configuration
├─ skills/            # professional capability packages
├─ workflows/         # executable process definitions
├─ templates/         # Spec, ADR, Review, and other templates
├─ evaluations/       # offline benchmarks and real cases
├─ connectors/        # tool, MCP, and API descriptions
└─ catalog.yaml       # owner, version, dependency, rating, and status

Every asset moves through Draft → Pilot → Certified → Deprecated → Retired. Publication requires more than “it looks useful”: capability evaluation, permission review, a cost ceiling, observability, rollback, an owner, and a support boundary are mandatory.

#7. Agent Collaboration

Start with one Agent plus deterministic tools. Add multiple Agents only when work is genuinely parallel, requires independent professional judgment, or must isolate permissions.

#Standard engineering roles

• Discovery Agent: clarifies the goal, identifies domains, finds authoritative sources, and produces unknowns and an initial impact map.
• Spec Agent: turns intent into requirements, scenarios, non-goals, boundaries, and testable acceptance criteria.
• Architecture Agent: analyzes constraints, options, dependencies, risks, and ADRs without replacing the accountable architect.
• Implementation Agent: modifies code within an approved task, runs the narrowest validation, and retains evidence and diffs.
• Test Agent: derives independent tests from acceptance criteria and covers normal, boundary, exceptional, and regression paths.
• Review Agent: reviews correctness, architecture, security, maintainability, performance, and drift.

#When multiple Agents make sense

#Minimum Agent contract

name: implementation-agent
purpose: implement approved tasks with the smallest safe change
inputs:
  - approved_spec
  - task
  - context_pack
allowed_tools:
  - repository_read
  - scoped_repository_write
  - test_runner
required_outputs:
  - change_set
  - evidence
  - risks_and_limits
quality_gates:
  - format
  - lint
  - type_check
  - relevant_tests
stop_conditions:
  - conflicting_authoritative_sources
  - permission_expansion
  - high_risk_without_approval
  - insufficient_information

#8. The Standard Eight-Stage Delivery Workflow

Every stage defines inputs, actions, artifacts, automated gates, human accountability, and exit conditions.

#Stage 1 — Intake and risk classification

Input: business request, defect, technical task, or incident. Output: task card, goal, scope, initial risk level, and owner.

• Identify business value, affected users, and success metrics.
• Distinguish features, bugs, refactoring, experiments, and high-risk operations.
• Work without an owner, goal, or acceptance direction does not advance.

#Stage 2 — Domain discovery and impact analysis

Input: task card, domain catalog, code and contract graph. Output: Context Pack, impact map, unknowns, and dependent teams.

• Search for duplicate terms, capabilities, interfaces, and existing implementations.
• Check upstream and downstream systems, data, permissions, compatibility, and historical ADRs.
• High or critical risk is reported before work proceeds.

#Stage 3 — Specification and acceptance

Input: impact map and business intent. Output: proposal, requirements, Spec delta, and acceptance criteria.

• Document primary, boundary, and exceptional scenarios, non-goals, and migration requirements.
• Map each requirement to at least one acceptance criterion.
• The product or domain owner approves What.

#Stage 4 — Design, ADR, and task decomposition

Input: approved Spec. Output: design, ADR, contract delta, tasks, validation plan, and rollback.

• Record the approach, alternatives, trade-offs, boundaries, and failure strategy.
• Decompose work into independently verifiable batches that avoid overlapping file ownership.
• The Tech Lead or architect approves How and the risk posture.

#Stage 5 — Implementation and local validation

Input: approved task, Context Pack, and allowed paths. Output: minimal change set, unit tests, execution log, and risk note.

• Validate from narrow to broad: function or class, module, then integration.
• Never delete failing tests, suppress type errors, fail silently, or bypass hooks.
• Update task evidence as subtasks finish; chat is not the progress record.

#Stage 6 — Independent verification and review

Input: change set, Spec, and test evidence. Output: test report, review decision, drift report, and non-compliance matrix.

• Separate the reviewer from the implementer.
• Review correctness, security, performance, compatibility, observability, and documentation drift.
• Convert cross-cutting defects into organizational contracts or automated guards.

#Stage 7 — Merge, release, and production validation

Input: approved delivery evidence. Output: approval record, release package, release notes, monitoring, and rollback confirmation.

• Apply separation of duties and risk classification to production operations.
• Validate business metrics, error rate, latency, and critical invariants after release.
• Stop or roll back automatically when thresholds are breached, then transfer control to the owner.

#Stage 8 — Documentation write-back and organizational learning

Input: implementation, production evidence, and feedback. Output: new Current Truth, ADR status, cases, evaluations, and Skill improvements.

• Archive the Spec delta so formal documentation and code do not diverge.
• Add new failure modes to regression suites; extract repeated actions into Skills.
• Record why the work succeeded or failed, not only the final code.

#9. Context Engineering: Correct Information, Not More Information

Context is a governed supply chain: identify the task, route authoritative sources, filter by permission, compress on demand, retain citations, and improve through feedback.

#Five context layers

#Context Pack standard

A Context Pack contains:

• task summary, goal, scope, non-goals, and risk level;
• applicable organizational and module rules with priority and scope;
• related Specs, contracts, ADRs, code symbols, and tests;
• facts, hypotheses, conflicts, and unknowns presented separately;
• provenance, version or commit, owner, update time, and trust level for every source;
• token and cost budget, expiry conditions, and data classification.

Useful quality metrics include authoritative-source recall, citation correctness, stale-source rate, irrelevant-context ratio, token cost per successful task, and the frequency of human context correction.

#10. Knowledge and Memory

Knowledge is confirmed organizational truth. Memory is experience-derived information that may expire or be corrected. Conversation history must never be promoted directly into company knowledge.

A safe memory write pipeline is candidate → classification → evidence → conflict check → approval or policy → scoped storage → TTL and review. Memory must support scope isolation, provenance, correction, deletion, contradiction detection, expiration, and audit.

#11. Platform and Toolchain Reference Architecture

Build only what differentiates the organization. Adopt mature runtime components where possible and keep organizational assets in open, versioned formats.

The platform must support pause, resume, replay, and cancellation; identify every model, prompt, Skill, Context Pack, tool, and output version; provide timeout, retry, idempotency, rate limiting, circuit breaking, and compensation; allow models and tools to be replaced; and degrade gracefully so teams can still use Git-based Specs, templates, and scripts.

#12. Security, Permissions, and Compliance

An Agent is not a shared superuser. It acts on behalf of a person or service under explicit, temporary, least-privilege authorization.

#Six security baselines

1. Traceable identity: distinguish user, Agent, Workflow, and tool identities and record the delegation chain.
2. Least privilege: grant access by task, path, resource, and time; default to read-only.
3. Sensitive-data isolation: classify and redact data and enforce regional and provider policy before model or tool calls.
4. Side-effect classification: read, write, delete, publish, and payment operations use different approval and credential policies.
5. Complete audit: retain context provenance, tool parameters, response summaries, approvers, and final outcomes.
6. Supply-chain governance: version and review models, plugins, MCP servers, dependencies, prompts, and Skills.

Block the workflow when secrets or production data would enter an unapproved model; an Agent expands its own permissions; a production deletion, access grant, payment, or compliance decision would be self-approved; tool calls cannot be audited; external prompt injection can drive a high-risk tool; or generated dependencies and artifacts bypass normal supply-chain scanning.

#13. Evaluation, Observability, and Engineering Effectiveness

“It feels faster” is not a business case. Use four layers of evaluation and balance quality, speed, cost, and risk.

#Balanced metrics

Build evaluation sets from the previous three to six months of frequent work and high-loss failures. Preserve inputs, required context, stage expectations, final criteria, and forbidden behavior. Separate golden, regression, red-team, and exploratory suites, and rerun them whenever models, Skills, rules, tools, or context policy change.

#14. A 90-Day Adoption Roadmap

Prove one closed loop with one real team and one real value stream, then replicate it. Do not begin by building a large platform or covering every engineering scenario.

#Days 0–15: baseline and pilot selection

• Choose one team with clear business boundaries, fast feedback, and moderate risk.
• Sample 20–50 historical tasks and record cycle time, rework, defects, and cost.
• Inventory PRDs, documentation, rules, tools, knowledge bases, and permissions.
• Publish the pilot charter, success metrics, owner, and stop conditions.

#Days 16–30: establish the minimum protocol

• Publish organization constitution v0.1, risk classification, and human gates.
• Standardize Spec, Design, ADR, Task, and Review templates.
• Establish the domain glossary and minimum Context Pack.
• Implement three to five high-frequency Skills: discovery, Spec, impact analysis, testing, and review.

#Days 31–60: run the delivery loop

• Connect intake, Spec, implementation, verification, and write-back as a Workflow.
• Integrate Git and CI with schema, test, review, and drift gates.
• Capture complete traces, human edits, failures, token use, and cycle time.
• Evaluate weekly and improve Skills instead of stacking temporary prompts.

#Days 61–90: productize and replicate

• Build the minimum Registry with version, owner, and lifecycle governance.
• Publish a team starter kit, training, office hours, and support SLA.
• Blind-test whether a second team can onboard without the original builders.
• Produce the next-quarter roadmap for platform gaps, assets, budget, and risk.

Good first scenarios include code impact analysis, Spec and acceptance generation, code review, test generation and execution, incident diagnosis with tightly controlled production permissions, and documentation-drift detection.

#15. Maturity Model

Teams do not mature by declaring themselves “AI native.” They advance through verifiable evidence across process, assets, quality, governance, and business results.

#16. A Two-Week Team Startup Playbook

#Days 1–2: define the boundary

• Assign the team AI-native owner, domain owner, and quality owner.
• Choose one value stream and three upcoming real tasks.
• Record baseline cycle time, rework, defects, and human effort.
• Define operations and data that must never be automated.

#Days 3–5: prepare knowledge and rules

• Confirm module rules, architecture boundaries, and engineering standards.
• Document the first 20 core terms, key business rules, and interface authorities.
• Add Spec, ADR, and Review templates and directory conventions.
• Remove duplicate, stale, or conflicting instructions.

#Days 6–8: configure capabilities

• Select approved models and engineering entry points.
• Enable impact-analysis, Spec, implementation, test, and review Skills.
• Configure tool allowlists, writable paths, and approvals by risk.
• Connect the narrowest tests, lint, and contract checks to automated gates.

#Days 9–10: blind run and limited launch

• Ask a member who did not configure the system to complete one end-to-end task.
• Record missing context, misunderstandings, ineffective steps, human corrections, and cost.
• Repair the Workflow or Skill instead of appending another temporary prompt.
• Enter a limited pilot only after the launch checklist passes.

#17. Reusable Templates

Templates are minimum information protocols, not demands for long documents. Low-risk work may omit optional detail; high-risk work must include evidence, approval, and rollback.

#Change Proposal

# Change Proposal: [title]

## Why
- Problem and evidence:
- Affected users:
- Success metric:

## Scope
- In scope:
- Out of scope:

## What Changes
- Added:
- Modified:
- Removed:

## Risk
- Level:
- Impact:
- Migration and rollback:

## Ownership
- Product owner:
- Technical owner:
- Approvers:

#Skill Contract

name: skill-name
purpose: the problem this Skill solves
triggers: when it must or may be used
non_goals: what it does not solve
inputs:
  - name: input-name
    schema: schema-reference
    required: true
preconditions:
  - authoritative sources, permissions, environment
steps:
  - action, tool, and intermediate evidence
outputs:
  - artifact, schema, and location
quality_gates:
  - deterministic checks and human gates
stop_conditions:
  - conflict, privilege expansion, high risk, insufficient information
failure_strategy:
  - retry, fallback, rollback, escalation
evaluation:
  - cases, metrics, pass threshold
owner: team/name
version: semver

#Agent Delivery Report

## Outcome
What was completed and whether the goal was met.

## Changes
- Files or systems changed:
- Important behavior changes:

## Evidence
- Tests and results:
- Referenced Specs, ADRs, and contracts:
- Traces and logs:

## Risks and Limits
- Uncovered items:
- Known risks:
- Assumptions:

## Drift
- Documentation or contracts requiring synchronization:

## Human Decision Needed
- Who must decide what; write "none" when no decision remains.

#18. Open-Source Building Blocks

Adopt mature patterns, keep assets open, and validate through pilots. Do not bind the organizational method to one framework.

#19. Common Anti-Patterns

#20. Acceptance Checklist

An organization may call its R&D process AI native only when the system survives changes in model, personnel, and IDE.

#Minimum company-level acceptance

• The organizational constitution, risk classification, and human approval matrix are published.
• Agent, Skill, Workflow, and Evaluation assets follow common standards.
• Model and tool access is governed through identity, permission, and audit controls.
• Real-task evaluation sets, baselines, and regression on version changes exist.
• Assets have owners, versions, status, dependencies, support boundaries, and retirement policy.
• Quality, flow, cost, and risk appear in one balanced scorecard.
• At least two teams can adopt the system without depending on its original builders.

#Minimum team-level acceptance

• The team has explicit AI-native, domain, and quality owners.
• Real tasks follow Spec → Design → Task → Evidence.
• High-risk work includes impact analysis, human gates, and rollback.
• Agents access only the tools and paths required by the current task.
• Tests and review are independent from implementation and reproducible.
• Code, contract, and documentation drift is checked before delivery.
• Failure cases have been converted into Skills, guards, or evaluations.
• At least three real requirements have been delivered with results better than baseline.

#The final test

“

If the organization changes its model, key personnel, or IDE tomorrow, do the workflow, knowledge, evaluation, and accountability mechanisms still hold? If not, the system is not yet an organizational capability.

#Recommended next actions

1. Appoint one company-level AI-native owner and choose one pilot team.
2. Use this guide to establish the pilot charter, constitution v0.1, and evaluation baseline.
3. Adopt an OpenSpec-style change workflow and implement the first three to five Skills.
4. Complete the first real requirements within 30 days and use evidence to continue, adjust, or stop.