# AI-Native Engineering Platform — Vendor-Neutral Reference Architecture

This reference is intentionally vendor-neutral. It describes responsibilities and control boundaries rather than prescribing products.

## Core principle

**One engineering platform, multiple actors, one consistent control model.**

Human developers and AI agents may use different interfaces, but they should consume the same governed platform capabilities.

## Reference architecture

```text
Human developers        Coding agents        Operations agents
       │                      │                      │
       └──────────────┬───────┴──────────────┬───────┘
                      │                      │
              Portal / CLI / APIs / MCP / Git
                      │
              Engineering Control Plane
                      │
       ┌──────────────┼──────────────────────────────┐
       │              │              │               │
   Identity &      Context &      Policy &        Evaluation
   attribution     catalog        authority       & quality
       │              │              │               │
       └──────────────┼──────────────┴───────────────┘
                      │
              Governed capabilities
                      │
        ┌─────────────┼──────────────┬──────────────┐
        │             │              │              │
      Build         Deploy         Operate       Provision
        │             │              │              │
        └─────────────┴───────┬──────┴──────────────┘
                              │
                   Applications & infrastructure
                              │
                  Telemetry / evidence / cost
                              │
                         Control plane
```

## Layer 1 — Actors and interfaces

### Actors

- human developer
- service account
- CI/CD workflow
- coding agent
- operational agent
- long-running automation

### Interfaces

- developer portal
- CLI
- Git / pull request workflow
- platform API
- MCP or equivalent machine-tool interface
- event/workflow interface

**Invariant:** the interface should not determine the governance standard. An agent using an API should not receive broader authority than a human using the portal for the same platform capability.

## Layer 2 — Engineering control plane

### Identity and attribution

Responsibilities:

- authenticate actor
- distinguish initiator from executor
- carry agent/model/version metadata when relevant
- grant/revoke capabilities
- associate actions with team/service ownership

### Context and catalog

Responsibilities:

- service and resource ownership
- repository/runtime relationships
- dependency graph
- criticality and data classification
- supported deployment patterns
- operational runbooks
- environment restrictions
- approved agent capabilities

### Policy and authority

Responsibilities:

- classify action consequence
- enforce capability boundaries
- evaluate target/environment/action context
- require approval when consequence warrants it
- bind approval to the exact action
- reject malformed, unknown, expired, or revoked authority

### Evaluation and quality

Responsibilities:

- evaluate generated changes
- compare model/agent versions
- test scope correctness
- detect unnecessary high-risk actions
- retain critical failures as regression scenarios
- separate model, integration, governance, and executor failures

## Layer 3 — Governed platform capabilities

Prefer capabilities over raw infrastructure access.

Examples:

### Build

- create repository/service from approved template
- run tests
- build artifact
- request dependency
- generate documentation

### Deploy

- create deployment proposal
- deploy sandbox
- canary release
- promote release
- rollback

### Operate

- query telemetry
- inspect logs
- execute bounded diagnostic
- propose configuration change
- request/restart service

### Provision

- create sandbox environment
- request database/queue/storage
- configure approved networking pattern
- manage bounded lifecycle

A capability should expose only the parameters needed to perform the intended operation.

## Layer 4 — Applications and infrastructure

The control plane should mediate consequential access to:

- source repositories
- CI/CD systems
- runtime platforms
- cloud resources
- data stores
- observability systems
- security systems
- service catalogs
- secrets and credentials

Do not require agents to understand or directly administer every underlying product when a stable platform capability can represent the operation.

## Layer 5 — Evidence and feedback

Capture observable evidence such as:

```text
initiator
  ↓
agent / workflow identity
  ↓
task or intent
  ↓
proposed capability + arguments
  ↓
policy / approval decision
  ↓
executed action
  ↓
runtime outcome
  ↓
verification / rollback
```

Useful dimensions include:

- actor
- model/agent version
- service/resource
- environment
- policy version
- approval
- execution result
- latency
- model usage/cost
- infrastructure cost
- quality evaluation
- rollback/remediation

## Action classes

| Class | Example | Typical control |
|---|---|---|
| Read-only | inspect status, read metadata | autonomous |
| Isolated/reversible | run test, sandbox change | autonomous or policy-controlled |
| Collaborative | open PR, create proposal | autonomous with attribution |
| Consequential | production config/restart | policy + possible approval |
| Security-sensitive | weaken auth, change protection | strong approval or prohibited |
| Destructive | irreversible production deletion | strongly constrained or prohibited |

The table is illustrative. Organizations should set thresholds based on actual consequence.

## Recommended ownership model

### Platform engineering owns

- shared actor/identity patterns
- platform APIs and paved capabilities
- policy hooks
- catalog/context infrastructure
- evaluation infrastructure
- common telemetry/evidence
- reusable templates and workflows

### Domain/application teams own

- domain agents
- domain prompts/instructions
- domain-specific tools
- business correctness
- application/service lifecycle
- local evaluation scenarios

### Security/governance partners own or co-own

- policy requirements
- sensitive capability classes
- approval requirements
- security controls
- compliance evidence requirements

**Operating principle:** centralize the control plane; federate the intelligence.

## Review anti-patterns

### Agent admin account

Agents receive broad administrative credentials because product integrations are inconvenient.

### Portal-only paved road

Humans use governed self-service; agents bypass it and automate raw infrastructure.

### Prompt-as-policy

Production/security restrictions exist only in natural-language agent instructions.

### Tool visibility equals authority

If a tool appears in the model context, the system assumes the model may execute it.

### Central AI bottleneck

A central team must implement every agent and domain workflow.

### Unmeasured model upgrades

Agent/model versions change without replaying representative engineering scenarios.

## Adoption sequence

### Stage 1 — inventory

Identify existing platform capabilities, machine interfaces, identities, and consequential actions.

### Stage 2 — expose paved capabilities

Ensure important portal workflows have governed machine-consumable contracts.

### Stage 3 — attribute agents

Introduce explicit agent/workflow identities and action tracing.

### Stage 4 — classify authority

Define low-risk, approval-required, security-sensitive, and prohibited capability classes.

### Stage 5 — evaluate

Build scenario-based evaluation for agent behavior and model upgrades.

### Stage 6 — measure and adapt

Use failures, cost, latency, quality, and operational outcomes to revise policies and platform capabilities.

---

Companion resource: *The AI-Native Engineering Platform* and its readiness checklist at jacobpallattu.com.