AI agents are rapidly moving from experimentation to execution.

They no longer just suggest code changes, release notes, or infrastructure updates. Increasingly, they act: creating pull requests, tagging releases, updating Jira tickets, deploying services, or modifying production configurations.

This shift marks a fundamental transition—from AI as an assistant to AI as an operator.

And that transition exposes a critical gap.

We have given AI agents hands, but not boundaries.

At Relicta, we believe this gap will define the next era of AI adoption in engineering organizations.

The uncomfortable truth: agents are powerful—and ungoverned

Modern AI agents can:

  • Generate and merge code
  • Modify CI/CD pipelines
  • Trigger releases
  • Change configuration and feature flags
  • Interact with issue trackers, repos, cloud APIs, and internal tools

They do this by chaining tools, APIs, and credentials—often with broad permissions, limited oversight, and little organizational context.

In many teams today:

  • An agent has access because it can, not because it should
  • Approval is implicit, not explicit
  • Responsibility is blurred between human, system, and model

This works—until it doesn’t.

When something goes wrong, the questions become uncomfortable:

  • Who approved this action?
  • Under which policy?
  • Was this change compliant?
  • Could this agent even do that?
  • How do we prevent it from happening again?

These are not AI problems. They are governance problems.

Humans operate with permission. AI agents often don’t.

In mature engineering organizations, humans operate within well-defined boundaries:

  • Role-based access control (RBAC)
  • Change approval workflows
  • Release gates
  • Separation of duties
  • Audit trails
  • Compliance rules

A junior engineer cannot:

  • Push directly to production
  • Bypass security checks
  • Change billing or customer data
  • Release without approvals

But many AI agents today effectively can.

Why?

Because we connected them directly to production systems—without inserting the same governance layer we rely on for humans.

Why “just trusting the agent” does not scale

Early adopters often rely on informal safeguards:

  • “The agent only runs in staging”
  • “We review PRs manually”
  • “It’s fine, it’s deterministic”
  • “We trust this model”

This breaks down as:

  • The number of agents grows
  • Agents become autonomous
  • Actions span teams, repos, and environments
  • Compliance and audit requirements kick in
  • Incidents become harder to trace

Trust is not a control mechanism. Especially not at scale.

The missing layer: permissioned execution

What’s missing is not better models.

What’s missing is a governance layer between AI agents and production.

A layer that answers one simple question before any action:

Is this agent allowed to do this, in this context, right now?

At Relicta, we call this permissioned execution.

What permission means for AI agents

Permission is not just “yes” or “no”.

In a production-grade environment, permission includes:

1) Scope

What can this agent act on?

  • Repositories
  • Services
  • Environments
  • Product lines
  • Tenants

2) Action types

What is it allowed to do?

  • Read vs write
  • Propose vs execute
  • Deploy vs prepare
  • Modify config vs observe

3) Context

Under which conditions?

  • Business hours only
  • Certain release phases
  • Specific branches
  • Specific risk levels

4) Approval

Who must sign off?

  • Auto-approve
  • Human-in-the-loop
  • Multi-party approval
  • Policy-based approval

5) Auditability

Can we answer, later:

  • What happened?
  • Why it happened?
  • Who (or what) authorized it?

Without these dimensions, AI agents are operating outside the rules that govern every other production actor.

Relicta diagrams

Below are Relicta-specific diagrams you can render using Mermaid (supported by many Astro setups via remark/rehype plugins or MDX).

Diagram 1: Without governance vs. with Relicta

Ungoverned
flowchart TD
  AgentA["AI Agent"] -->|Direct API| GitHub["GitHub"]
  AgentA -->|Direct API| Cloud["Cloud"]
  AgentA -->|Direct API| Prod[("Production")]
→
Governed
flowchart TD
  AgentB["AI Agent"] -->|Intent| Relicta["Relicta"]
  Relicta -->|Policy| Gate{"Gate"}
  Gate -->|Approved| GitHub["GitHub"]
  Gate -->|Approved| Cloud["Cloud"]
  Relicta --> Audit["Audit"]

  classDef accent fill:#5cf0c8,stroke:#333,stroke-width:2px,color:currentColor;
  class Relicta accent;
Relicta introduces a control plane that validates intent before execution.

What changes: agents don’t “own” production privileges. They submit intent through Relicta, and Relicta decides what’s allowed, what needs approval, and what gets recorded.

Diagram 2: Permissioned execution decision flow

flowchart TD
  Start(["Agent proposes an action"]) --> Ctx["Attach context\n(repo/service/env/tenant/risk)"]
  Ctx --> Classify["Classify action\n(read/write/deploy/config/etc.)"]
  Classify --> Policy["Evaluate policy\n(RBAC + rules + constraints)"]
  Policy -->|Denied| Deny["Reject + Explain reason\n+ suggested safe alternative"]
  Policy -->|Allowed| ExecType{"Execution mode"}
  ExecType -->|Propose only| PR["Create proposal artifact\n(PR/plan/change request)"]
  ExecType -->|Auto-execute| Run["Execute via connectors"]
  ExecType -->|Needs approval| Approvals["Collect approvals\n(HITL / multi-party / time window)"]
  Approvals -->|Rejected| Deny
  Approvals -->|Approved| Run
  PR --> Evidence["Record evidence\n(policy decision, diffs, approvers)"]
  Run --> Evidence
  Evidence --> Done(["Action completed + auditable"])
The decision flow for permissioned execution
Key Takeaway: The default posture becomes controlled: deny by default, require approvals for risk, and always audit.

Diagram 3: Relicta policy model (org structure → permissions)

flowchart TB
    subgraph OrgStructure ["Organization Structure"]
        direction TB
        Org["Organization"] --> PL["Product Line"]
        PL --> SVC["Service"]
        SVC --> ENV["Environment"]
        Org --> TEN["Tenant / Customer"]
        Org --> TEAM["Team"]
    end

    subgraph AccessModel ["Access Model"]
        direction TB
        TEAM --> ROLE["Role"]
        ROLE -->|grants| PERM["Permissions"]
        Agent["AI Agent Identity"] -->|assumes| ROLE
    end

    PERM -.->|scoped to| PL
    PERM -.->|scoped to| SVC
    PERM -.->|scoped to| ENV
    PERM -.->|scoped to| TEN

    Agent -->|requests| ACT["Action Intent"]
    ACT -->|evaluated by| PERM

    classDef accent fill:#5cf0c8,stroke:#333,stroke-width:2px,color:#04140e;
    class PERM accent;

    style OrgStructure fill:transparent,stroke:#333,stroke-dasharray: 5 5
    style AccessModel fill:transparent,stroke:#333,stroke-dasharray: 5 5
How permissions map to organization structure
Key Takeaway: Permissions aren’t just 'tool access.' They’re scoped to product lines, services, environments, and tenants.

Diagram 4: Relicta as the control plane for agent/tool ecosystems

flowchart TB
  subgraph Agents
    direction LR
    A1["Release Agent"]
    A2["Incident Agent"]
    A3["Migration Agent"]
    A4["Changelog Agent"]
  end

  subgraph RelictaCP ["Relicta Control Plane"]
    direction TB
    I["Intent API"] --> P["Policy Engine"]
    P --> Ap["Approvals"]
    Ap --> Co["Connectors"]
    P --> Au["Audit + Evidence"]
    Ap --> Au
    Co --> Au
  end

  subgraph Systems
    direction LR
    GH["GitHub / GitLab"]
    CI["CI/CD"]
    J["Jira / Linear"]
    K["Kubernetes / Cloud"]
    F["Feature Flags"]
    D["Datastores"]
  end

  Agents --> I
  Co --> Systems

  classDef accent fill:#5cf0c8,stroke:#333,stroke-width:2px,color:currentColor;
  class RelictaCP accent;
Relicta acting as the governed highway
Key Takeaway: Relicta sits between agents and the systems that change production, ensuring every action is governed.

Translation: Relicta is the “governed highway” between agents and the systems that can change production.

Relicta: the governance layer for AI-driven delivery

Relicta exists precisely to fill the gap between agent capability and production responsibility.

It acts as a control plane between:

  • AI agents
  • Engineering systems (GitHub, CI/CD, Jira, cloud, registries)
  • Organizational rules and policies

Instead of agents acting directly on production systems, they act through Relicta.

Relicta:

  • Evaluates intent
  • Enforces policy
  • Requires approvals
  • Records decisions
  • Provides traceability

In other words:

Relicta makes AI agents first-class, governed citizens of your delivery ecosystem.

Why this matters now (not later)

This problem will not appear “eventually”.

It is already here.

  • Teams are deploying AI-assisted releases
  • Autonomous agents are becoming normal
  • Regulators are paying attention
  • Enterprises are asking hard questions
  • Auditors will ask harder ones

The organizations that scale AI safely will not be the ones with the best prompts—but the ones with the strongest governance primitives.

The future: agents as teammates, not shadow operators

AI agents are not going away. They will become more capable, more autonomous, and more embedded.

The choice is not whether to use them.

The choice is whether they operate:

  • Inside your rules
  • Or outside your control

Relicta’s vision is simple:

AI agents should be as powerful as humans—and at least as governed.

Permission is not friction. Permission is what makes scale possible.

Want to learn more?

Relicta is building the permission and governance layer for AI-driven delivery, releases, and service ecosystems.

If you’re experimenting with agents—or already running them in production—this layer is no longer optional.

It’s inevitable.