DEV Community

Cover image for From Prompts to Policies: Why AI Engineering Needs a Control Plane
bayu priatno
bayu priatno

Posted on

From Prompts to Policies: Why AI Engineering Needs a Control Plane

#ai #softwareengineering #development #opensource

The next generation of AI engineering will not be controlled by prompts alone.

AI coding agents are becoming remarkably capable.

They can inspect repositories, write code, modify multiple files, run tests, analyze failures, interact with development tools, and increasingly execute complex engineering workflows.

This changes the nature of software development.

The question is no longer simply:

"What should we ask the AI to build?"

The more important question becomes:

"How do we control what an AI agent is allowed to do?"

This is where the concept of an AI Engineering Control Plane becomes important.

And it is one of the architectural ideas behind NAEOS — Nusantara AI Engineering Operating System.

1. The Prompt Is Not a Governance System

The modern AI development workflow often looks like this:

Developer
   ↓
Prompt
   ↓
AI Agent
   ↓
Code
Enter fullscreen mode Exit fullscreen mode

This works surprisingly well for small tasks.

But consider what happens when the agent gains more capabilities.

The agent may be able to:

  • modify source code
  • execute shell commands
  • access databases
  • modify infrastructure
  • call external APIs
  • create cloud resources
  • deploy applications
  • access engineering documentation
  • interact with CI/CD systems

Suddenly, the prompt is no longer enough.

A prompt can say:

"Don't modify production."

But if the system technically allows the agent to modify production, the restriction exists only as an instruction.

That is not a strong control.

There is a fundamental difference between:

telling an agent what not to do

and

making the action impossible without authorization.

2. Instructions vs Controls

Consider two scenarios.

Scenario A — Instruction 

System Prompt:

Do not deploy directly to production.
Always ask for approval.
Enter fullscreen mode Exit fullscreen mode

The agent understands the instruction.

But the underlying tooling may still provide:

production.deploy
Enter fullscreen mode Exit fullscreen mode

The restriction is behavioral.

Scenario B — Control 

Agent
  ↓
Policy Engine
  ↓
Authorization
  ↓
Capability Check
  ↓
Deployment System
Enter fullscreen mode Exit fullscreen mode

If the agent is not authorized:

DENY
Enter fullscreen mode Exit fullscreen mode

The agent cannot simply reason its way around the restriction.

This distinction becomes increasingly important as AI agents become autonomous.

3. What Is a Control Plane?

In distributed systems, a control plane is responsible for defining and coordinating how a system should operate.

A similar concept can be applied to AI engineering.

An AI Engineering Control Plane can manage:

Identity
Permissions
Policies
Knowledge
Planning
Workflows
Capabilities
Quality Gates
Validation
Execution Rules
Audit
Observability
Enter fullscreen mode Exit fullscreen mode

Instead of:

Prompt → Agent → Action
Enter fullscreen mode Exit fullscreen mode

we move toward:

Intent
  ↓
Policy
  ↓
Knowledge
  ↓
Plan
  ↓
Authorization
  ↓
Agent
  ↓
Execution
  ↓
Validation
  ↓
Audit
Enter fullscreen mode Exit fullscreen mode

The AI agent becomes one component inside a larger engineering system.

4. Why This Matters

Imagine an agent receives this task:

"Upgrade the database infrastructure."

That sentence is insufficient to determine what the agent should actually do.

The system needs to know:

Which environment?

Which database?

Which version?

What architecture policy applies?

What maintenance window applies?

What backup requirements exist?

What security requirements apply?

What tests are required?

Who must approve the change?

What rollback strategy is required?
Enter fullscreen mode Exit fullscreen mode

The agent needs more than a prompt.

It needs an engineering context.

And the control plane is responsible for assembling and enforcing that context.

5. The Control Plane Model

A conceptual NAEOS control plane can be represented as:

                    HUMAN INTENT
                         │
                         ▼
                ┌─────────────────┐
                │   GOVERNANCE    │
                └────────┬────────┘
                         ▼
                ┌─────────────────┐
                │  CONSTITUTION   │
                └────────┬────────┘
                         ▼
                ┌─────────────────┐
                │    KNOWLEDGE    │
                └────────┬────────┘
                         ▼
                ┌─────────────────┐
                │  POLICY ENGINE  │
                └────────┬────────┘
                         ▼
                ┌─────────────────┐
                │  PLAN / WORKFLOW│
                └────────┬────────┘
                         ▼
                ┌─────────────────┐
                │    AI AGENT     │
                └────────┬────────┘
                         ▼
                ┌─────────────────┐
                │    EXECUTION    │
                └────────┬────────┘
                         ▼
                ┌─────────────────┐
                │ VALIDATION/AUDIT│
                └─────────────────┘
Enter fullscreen mode Exit fullscreen mode

The control plane does not need to replace the AI agent.

It governs the environment in which the agent operates.

6. Policy Becomes the Execution Contract

A policy should not simply be a document that humans read.

For AI-native engineering, policies should increasingly become machine-readable.

For example:

policy:
  id: deployment.production
  version: 3.2.0
  status: active

rules:
  require_tests: true
  require_security_scan: true
  require_approval: true
  require_audit: true

environment:
  production:
    direct_agent_deployment: false

risk:
  level: high
Enter fullscreen mode Exit fullscreen mode

This policy can then be consumed by the engineering control plane.

The important transition is:

Policy as Documentation
        ↓
Policy as Machine-Readable Rule
        ↓
Policy as Runtime Control
Enter fullscreen mode Exit fullscreen mode

This is a significant step toward governed AI engineering.

7. The Policy Engine

The Policy Engine becomes one of the most important components of the control plane.

Its responsibility is to answer questions such as:

Is this agent allowed to perform this action?

Is this resource within the agent's scope?

Is the environment permitted?

Are required validations complete?

Is human approval required?

Does another policy prohibit the action?
Enter fullscreen mode Exit fullscreen mode

Conceptually:

Agent Request
      │
      ▼
┌──────────────────┐
│  Policy Engine   │
└────────┬─────────┘
         │
   ┌─────┼─────┐
   ▼     ▼     ▼
Identity Scope Risk
   │     │     │
   └─────┼─────┘
         ▼
   Policy Decision
         │
   ┌─────┼───────────┐
   ▼     ▼           ▼
 ALLOW  DENY     ESCALATE
Enter fullscreen mode Exit fullscreen mode

This creates an explicit authorization boundary.

8. Allow, Deny, or Escalate

A mature AI engineering system should not have only two outcomes.

It should support at least three:

ALLOW
DENY
REQUIRE APPROVAL
Enter fullscreen mode Exit fullscreen mode

For example:

Low-risk action 

Run unit tests.

→ ALLOW
Enter fullscreen mode Exit fullscreen mode

Forbidden action 

Read production credentials.

→ DENY
Enter fullscreen mode Exit fullscreen mode

High-risk action 

Deploy new database migration to production.

→ REQUIRE HUMAN APPROVAL
Enter fullscreen mode Exit fullscreen mode

This enables risk-based autonomy.

9. Risk-Based Autonomy

Not every task deserves the same level of human involvement.

A useful model is:

                    HIGH AUTONOMY
                         ▲
                         │
                ┌────────┴────────┐
                │                 │
          Low-risk tasks     Medium-risk tasks
                │                 │
                ▼                 ▼
             Agent            Agent + Review
                                    │
                                    ▼
                              High-risk tasks
                                    │
                                    ▼
                            Human Approval
Enter fullscreen mode Exit fullscreen mode

This allows organizations to automate aggressively where the risk is low while maintaining stronger controls around critical operations.

The goal is not:

"Human approval everywhere."

The goal is:

"The right amount of human control for the level of risk."

10. Capability-Based Agents

Another important concept is capability-based access.

Instead of giving an agent broad access to a system, capabilities should be explicitly defined.

For example:

Agent Capabilities

repository.read
repository.write
tests.execute
build.execute
staging.deploy
production.deploy
database.read
database.write
infrastructure.modify
Enter fullscreen mode Exit fullscreen mode

An agent may receive:

repository.read
repository.write
tests.execute
staging.deploy
Enter fullscreen mode Exit fullscreen mode

but not:

production.deploy
database.write
infrastructure.modify
Enter fullscreen mode Exit fullscreen mode

This creates a much smaller blast radius.

11. Capability Is Not Permission

This distinction is subtle but important.

An agent may technically have the capability to call an API.

That does not mean the action is authorized.

For example:

Tool Capability
      ↓
"Can call deployment API"
Enter fullscreen mode Exit fullscreen mode

does not automatically mean:

Policy Authorization
      ↓
"May deploy this service to production"
Enter fullscreen mode Exit fullscreen mode

The control plane should evaluate both.

Agent
  ↓
Capability
  ↓
Identity
  ↓
Resource
  ↓
Policy
  ↓
Risk
  ↓
Decision
Enter fullscreen mode Exit fullscreen mode

This separation is essential for enterprise security.

12. The Control Plane Needs Knowledge

Policies alone are not enough.

The system also needs knowledge.

Suppose an agent wants to modify a service.

The policy engine may know:

"Production changes require approval."
Enter fullscreen mode Exit fullscreen mode

But the agent also needs to understand:

Which service?

Which architecture?

Which dependencies?

Which API contracts?

Which database?

Which previous decisions?

Which tests?

Which deployment procedure?
Enter fullscreen mode Exit fullscreen mode

This is why the architecture developed in the previous articles matters.

The control plane connects:

Constitution
+
Knowledge
+
Policy
+
Workflow
+
AI Agent
Enter fullscreen mode Exit fullscreen mode

into one engineering environment.

13. From RAG to Policy-Aware Retrieval

Traditional RAG asks:

"Which documents are relevant?"

An enterprise AI engineering system should ask:

"Which authorized engineering knowledge is relevant to this action?"

That introduces another dimension:

Relevance
+
Authority
+
Scope
+
Security
+
Freshness
+
Relationship
Enter fullscreen mode Exit fullscreen mode

For example, a developer may have access to ten architecture documents.

Only three may apply to the current project.

Of those three, one may be deprecated.

Another may be superseded.

The control plane should help the agent retrieve:

the correct, authorized, current knowledge.

14. Workflow Orchestration

The control plane also coordinates workflows.

Consider a production deployment:

Build
 ↓
Unit Tests
 ↓
Integration Tests
 ↓
Security Scan
 ↓
Artifact Verification
 ↓
Policy Check
 ↓
Approval
 ↓
Deployment
 ↓
Smoke Test
 ↓
Observability
Enter fullscreen mode Exit fullscreen mode

An AI agent may perform several of these steps.

But the workflow itself should remain governed.

The agent should not be able to arbitrarily skip:

Security Scan
Enter fullscreen mode Exit fullscreen mode

simply because it believes the change is safe.

The workflow engine and policy engine enforce the engineering process.

15. Quality Gates

Quality gates are another important component.

A quality gate defines conditions that must be satisfied before an action can proceed.

For example:

Pull Request
    ↓
Tests Passed?
    │
    ├── NO → STOP
    │
    └── YES
          ↓
Security Scan Passed?
    │
    ├── NO → STOP
    │
    └── YES
          ↓
Architecture Valid?
    │
    ├── NO → STOP
    │
    └── YES
          ↓
Approval
Enter fullscreen mode Exit fullscreen mode

This converts engineering standards into enforceable checkpoints.

16. The Agent Should Not Be the Final Authority

This is an important architectural principle.

An AI agent can:

  • propose
  • analyze
  • implement
  • test
  • reason
  • recommend

But for high-risk operations, the agent should not necessarily be the final authority.

Instead:

AI Agent
   ↓
Proposal
   ↓
Policy Engine
   ↓
Validation
   ↓
Human / Governance
   ↓
Authorization
   ↓
Execution
Enter fullscreen mode Exit fullscreen mode

This separates reasoning from authority.

That separation becomes increasingly important as agents become more autonomous.

17. Auditability

Every significant agent action should produce an audit trail.

For example:

Agent: security-agent-01

Action:
Modify authentication configuration

Resource:
service.payment-api

Policy:
security.authentication.v5

Decision:
ALLOW

Validation:
PASSED

Approval:
architecture-team

Timestamp:
2026-08-27T14:31:00Z
Enter fullscreen mode Exit fullscreen mode

The objective is to answer:

Who acted?

What happened?

Why was it allowed?

Which policy applied?

Which knowledge was used?

What changed?

Who approved it?

What was the outcome?
Enter fullscreen mode Exit fullscreen mode

This creates engineering traceability.

18. Observability for AI Engineering

Traditional observability focuses on applications and infrastructure.

AI-native engineering requires another layer.

We need to observe:

Agent Activity
Tool Usage
Policy Decisions
Knowledge Retrieval
Workflow Execution
Validation Results
Human Approvals
Failures
Retries
Cost
Latency
Outcomes
Enter fullscreen mode Exit fullscreen mode

A possible architecture:

AI Agent
   │
   ├── Logs
   ├── Metrics
   ├── Traces
   ├── Policy Events
   ├── Tool Events
   └── Knowledge Events
            │
            ▼
      Observability
            │
            ▼
        Analytics
            │
            ▼
       Improvement
Enter fullscreen mode Exit fullscreen mode

This creates visibility into the engineering system itself.

19. The Feedback Loop

The control plane should not be static.

Engineering outcomes should feed back into the system.

For example:

Agent Action
    ↓
Execution
    ↓
Outcome
    ↓
Observation
    ↓
Analysis
    ↓
Policy Improvement
    ↓
Knowledge Update
    ↓
Better Future Execution
Enter fullscreen mode Exit fullscreen mode

This produces a continuous learning loop.

But importantly:

learning should not mean uncontrolled self-modification.

Changes to policies, constitutions, and authoritative knowledge should remain governed.

20. Controlled Learning

There is a difference between:

AI learning from experience

and

AI changing the rules of the organization.

An agent might discover:

"This deployment procedure frequently fails because dependency X is unavailable."

That observation can become:

Candidate Knowledge
Enter fullscreen mode Exit fullscreen mode

It should then go through:

Validation
 ↓
Review
 ↓
Approval
 ↓
Knowledge Update
Enter fullscreen mode Exit fullscreen mode

The agent should not automatically rewrite an enterprise policy.

This preserves governance while enabling organizational learning.

21. NAEOS as an Engineering Control Plane

This is where NAEOS brings the concepts together.

The NAEOS model can be viewed as:

┌─────────────────────────────────────┐
│             GOVERNANCE              │
├─────────────────────────────────────┤
│            CONSTITUTION             │
├─────────────────────────────────────┤
│             KNOWLEDGE               │
├─────────────────────────────────────┤
│          POLICY ENGINE              │
├─────────────────────────────────────┤
│       WORKFLOW / PLANNING           │
├─────────────────────────────────────┤
│           QUALITY GATES             │
├─────────────────────────────────────┤
│             AI AGENTS               │
├─────────────────────────────────────┤
│          ENGINEERING TOOLS          │
├─────────────────────────────────────┤
│        VALIDATION & AUDIT           │
├─────────────────────────────────────┤
│       OBSERVABILITY & MEMORY        │
└─────────────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

The AI agent is not the operating system.

It is a participant inside the operating system.

That distinction is central to NAEOS.

22. Why This Architecture Is Vendor Neutral

A control plane also provides an important abstraction.

The organization should not need to redesign its engineering governance every time it changes AI providers.

For example:

                  NAEOS
                    │
       ┌────────────┼────────────┐
       │            │            │
     Agent A      Agent B      Agent C
       │            │            │
     Model A      Model B      Model C
Enter fullscreen mode Exit fullscreen mode

The agents can change.

The models can change.

The tools can change.

But the organization's:

Policies
Architecture
Knowledge
Security
Quality Gates
Governance
Enter fullscreen mode Exit fullscreen mode

remain stable.

This creates a valuable separation between AI capability and engineering governance.

23. The New Engineering Stack

Traditional software engineering stacks look roughly like:

Developer
   ↓
IDE
   ↓
Code
   ↓
Git
   ↓
CI/CD
   ↓
Infrastructure
Enter fullscreen mode Exit fullscreen mode

The AI-native engineering stack increasingly looks more like:

Human Intent
      ↓
Engineering Governance
      ↓
Knowledge
      ↓
Policy
      ↓
Planning
      ↓
AI Agents
      ↓
Tools
      ↓
Execution
      ↓
Validation
      ↓
Observability
      ↓
Organizational Memory
Enter fullscreen mode Exit fullscreen mode

The difference is significant.

The engineering system becomes the layer that coordinates humans, AI, knowledge, policies, and execution.

24. From AI Assistant to AI Engineer

This architectural shift changes how we think about AI agents.

An assistant waits for instructions.

An engineering agent can:

Understand
Plan
Act
Validate
Recover
Collaborate
Learn
Enter fullscreen mode Exit fullscreen mode

But increasing capability requires increasing structure.

The progression might look like:

Autocomplete
    ↓
Assistant
    ↓
Agent
    ↓
Multi-Agent System
    ↓
Autonomous Engineering
Enter fullscreen mode Exit fullscreen mode

As we move down this path:

Capability ↑
Autonomy ↑
Impact ↑
Risk ↑
Enter fullscreen mode Exit fullscreen mode

Therefore:

Governance ↑
Policy ↑
Observability ↑
Validation ↑
Enter fullscreen mode Exit fullscreen mode

must increase as well.

25. The Principle of Controlled Autonomy

This leads to a principle that I believe will become increasingly important:

Autonomy should be proportional to trust, context, validation, and control.

Not every agent should have the same autonomy.

Not every environment should have the same restrictions.

Not every task should require the same approval.

The system should dynamically determine the appropriate level of autonomy based on:

Agent
+
Task
+
Resource
+
Environment
+
Policy
+
Risk
+
Validation
Enter fullscreen mode Exit fullscreen mode

This is controlled autonomy.

26. The Bigger Shift

The software industry spent decades building infrastructure around human developers.

Now we are entering an era where software development includes increasingly autonomous machine participants.

That means we need new infrastructure.

Not necessarily another coding interface.

Not necessarily another model.

Not necessarily another prompt framework.

But an engineering layer that answers:

What can an agent know?

What can an agent do?

What should an agent do?

What must an agent never do?

When should an agent ask for help?

How do we validate its work?

How do we audit its decisions?

How do we learn from its outcomes?
Enter fullscreen mode Exit fullscreen mode

That is the role of an AI Engineering Control Plane.

27. Where NAEOS Fits

NAEOS is exploring this architecture as an Engineering Operating System for AI-native software development.

Its central idea is to connect:

Governance
      ↓
Constitution
      ↓
Knowledge
      ↓
Policy
      ↓
Workflow
      ↓
AI Agents
      ↓
Execution
      ↓
Validation
      ↓
Audit
      ↓
Memory
      ↓
Continuous Improvement
Enter fullscreen mode Exit fullscreen mode

The objective is not to eliminate human engineers.

It is to give humans and AI agents a common engineering system.

Conclusion

AI agents are becoming increasingly autonomous.

That is exciting.

But autonomy without governance creates risk.

And governance without automation creates bureaucracy.

The challenge is to build a system that enables both:

high automation and strong control.

That requires moving beyond prompts.

It requires:

Policies.

Capabilities.

Knowledge.

Workflows.

Quality Gates.

Authorization.

Validation.

Auditability.

Observability.

The next generation of AI engineering may therefore need something analogous to a control plane:

A system that does not merely tell AI agents what to do, but governs what they are allowed to know, decide, and execute.

That is the direction NAEOS is exploring.

Don't just give AI agents more tools.

Give them an engineering control plane.

Top comments (3)

Collapse
 
crdtcto profile image
Kane Lim •

This is a strong architectural direction, especially the distinction between agent capability and actual authorization.

The point that stands out to me is that prompts should be treated as intent/context, not as the security boundary. Once an agent can execute tools, modify repositories, access infrastructure, or trigger deployments, enforcement needs to exist outside the model through deterministic controls.

I’d extend the control-plane model with one additional principle: every consequential action should be evaluated as a policy decision over a specific identity, capability, resource, environment, and risk context.

For example:

Agent → Intent → Policy → Capability → Resource Scope → Risk → Validation → Decision

That makes ALLOW / DENY / ESCALATE auditable rather than dependent on whether the model correctly interpreted a system prompt.

I also think the separation between reasoning and authority is critical. An agent can propose a migration, generate the implementation, run validation, and even prepare the deployment—but the authority to execute a high-impact change should come from an external enforcement layer.

The other interesting challenge is policy drift. Machine-readable policies are useful only if versioned, testable, observable, and themselves governed. Otherwise the control plane can gradually become another source of hidden complexity.

Ultimately, I see the architecture moving toward controlled autonomy rather than unrestricted autonomy: give agents maximum freedom inside clearly defined boundaries, and progressively tighten those boundaries as blast radius and uncertainty increase.

This is an area I’m actively interested in from the engineering/automation side. I’d be glad to exchange ideas and explore whether there’s potential for a longer-term technical collaboration.

Collapse
 
bayu911 profile image
bayu priatno •

I really like this framing. I think the distinction between intent, capability, and authority is one of the most important pieces of the architecture.

I especially agree with your point on policy drift. A policy engine itself needs to be treated as an engineered system — versioned, testable, observable, auditable, and subject to governance. Otherwise, we risk replacing prompt-based ambiguity with policy-based complexity.

The model you proposed is close to how I’m thinking about NAEOS as well:

Agent → Intent → Policy → Capability → Resource Scope → Risk → Validation → Decision

What makes this interesting is that the same framework can potentially work across different agents, models, and toolchains while keeping the enforcement layer independent from the model.

I also strongly agree that reasoning and authority should remain separate. An agent should be able to reason, propose, implement, and validate — while consequential authority remains with an external, deterministic control layer.

I’d be very interested in exploring this further, particularly around policy versioning, policy testing, risk-based autonomy, and preventing policy drift in multi-agent engineering environments.

Your perspective from the engineering/automation side sounds highly aligned with what I’m exploring with NAEOS. I’d definitely be open to exchanging ideas and seeing where we can take this technically.

Some comments may only be visible to logged-in visitors. Sign in to view all comments.