DevOps & Automation | Harness Blog Primary Category

Technical

Your AI Agents Are Only As Good As Your Data

Correctness, groundedness, safety, efficiency — every dimension of agent quality traces back to the same thing: structured access to well-modeled data.

Sunil Gattupalle

April 13, 2026

Time to read

The Five-Minute Demo Problem

Every agent demo follows the same arc. The agent calls an API. A deployment triggers. A ticket gets created. The audience is impressed.

Then someone asks a real question: "Which regions had the highest order failure rate this quarter, and are any of them linked to vendor SLA breaches?"

That question crosses four entity types — orders, fulfillment records, vendors, SLA contracts. Without structured access to the underlying data, answering it means discovering which APIs exist, paginating through thousands of verbose JSON records, inferring which field names correspond across responses, and computing aggregations in the context window. A lot of work for both the agent and the infrastructure — and the context window bears the cost.

Now consider what happens when the agent has structured data infrastructure underneath:

User:  Which regions had the highest order failure rate this quarter,
       and are any linked to vendor SLA breaches?
 
Agent → describe(type='order')
  ← fields: region, status, created_at, vendor_id
  ← aggregations: COUNT, SUM supported on status; GROUP BY on region
 
Agent → related_types(type='order')
  ← Order →[has_vendor]→ Vendor →[governed_by]→ Contract
  ← join keys declared: order.vendor_id = vendor.id,
     vendor.contract_id = contract.id
 
Agent → validate(query="""
  SELECT region,
         COUNT(*) AS total,
         SUM(CASE WHEN status='failed' THEN 1 END) / COUNT(*) AS failure_rate,
         COUNT(CASE WHEN contract.sla_breached THEN 1 END) AS sla_breaches
  FROM orders
  JOIN vendors ON orders.vendor_id = vendors.id
  JOIN contracts ON vendors.contract_id = contracts.id
  WHERE created_at >= '2025-01-01'
  GROUP BY region
  ORDER BY failure_rate DESC
""")
  ← Valid. Estimated result: 6 rows.
 
Agent → run(query=...)
  ← | region | total | failure_rate | sla_breaches |
     | APAC   |  1247 |        0.083 |            3 |
     | EMEA   |   893 |        0.071 |            1 |
     | NA     |  2104 |        0.042 |            0 |
 
Agent:  APAC has the highest order failure rate at 8.3% this quarter,
        with 3 linked SLA breaches. EMEA follows at 7.1% with 1 breach.
        North America is lowest at 4.2% with no breaches.

Four tool calls. ~800 tokens of context consumed. A correct, verifiable answer. The query is validated against a formal schema before execution, so invalid field names are caught early. The joins are declared in the relationship graph. Aggregation happens at the data layer, not in the LLM's working memory.

The structure does the heavy lifting — the agent focuses on understanding the question and interpreting the result.

Agent Quality Has Dimensions

When you evaluate agents rigorously, quality breaks down along specific dimensions. What's striking is that every one of them maps to a data infrastructure capability.

Three foundational data architecture concepts do most of the work: a domain ontology (entity types, fields, constraints), a relationship graph (declared joins with explicit keys and cardinality), and a query engine (validate-then-execute against a formal grammar). These are the primitives that take years to build. Layer on data-layer access control and a dispatch table for tool routing, and you get a complete mapping from infrastructure to agent quality:

Dimension	What it asks	Infrastructure capability
Correctness	Is the answer right?	Ontology
Groundedness	Is it supported by evidence?	Relationship Graph
Safety	Did it violate policy?	Access Control
Trajectory	Did it take a good path?	Dispatch Table
Performance	Was it fast and cheap?	Query Engine

Fig. 2 — Infrastructure capabilities map to quality dimensions

Correctness: Ontologies Turn Silent Errors Into Loud Ones

An ontology — a formal description of entity types, their fields, and their valid operations — does for agents what a type system does for code. It makes invalid operations visible before they execute.

A well-modeled field isn't just a name and a data type. It carries operational constraints: this field is numeric, measured in milliseconds, supports SUM/AVG/P95, is sortable but not groupable because it's continuous. When an agent generates GROUP BY fulfillment_time, that's a semantic error caught before execution. When it generates WHERE status = 'falied', validation returns "did you mean 'failed'?" and the agent retries.

Here's what that looks like in practice:

Agent → validate(query="SELECT region, GROUP BY fulfillment_time ...")
  ← Error: fulfillment_time is a continuous numeric field (milliseconds).
     GROUP BY is not supported. Supported operations: SUM, AVG, P95, MIN, MAX.
     Did you mean GROUP BY region?
 
Agent → validate(query="SELECT region, ... WHERE status = 'falied' ...")
  ← Error: 'falied' is not a valid value for field status.
     Valid values: 'active', 'failed', 'completed', 'pending'.
 
// Both errors caught before any data is queried.
// The agent retries with corrected fields and gets a valid result.

// Both errors caught before any data is queried.

// The agent retries with corrected fields and gets a valid result.

This is the difference between approximately right and verifiably right. With an ontology, you can prove correctness by validating the query before it ever touches the data. Errors become loud and fixable — not silent and compounding. And because correctness is now deterministic, it becomes measurable:

ExactMatch: Does the agent's structured query return the same result as the gold query? Testable, because both are deterministic.
TaskCompletion: Did the agent answer the full question, including the SLA breach correlation? Achievable, because the relationship graph told it the join existed.

Groundedness: The Relationship Graph Is the Citation Layer

Groundedness asks: can the agent point to where its answer came from?

When every answer traces to a specific query, validated against a specific schema, executed against a specific data source — the agent can cite its work:

"Failure rate of 8.3% for APAC: computed as SUM(status='failed') / COUNT(*) on the orders table, filtered to Q1 2025, grouped by region. Joins: orders.vendor_id → vendors.id → contracts.contract_id. Source query validated against schema version 2.4.1."

The relationship graph is what makes this possible for cross-entity questions. When the agent discovers that Order relates to Vendor via vendor_id, and Vendor relates to Contract via contract_id, those aren't inferences — they're declared edges with explicit join keys, cardinality, and traversal names.

Every relationship the agent uses is traceable to a declared edge. If something looks off, you can follow the chain: was the join key correct? Was the cardinality right? Was the traversal path valid? Debugging becomes inspection, not guesswork.

This matters especially as domain complexity grows. When relationships are declared explicitly — rather than inferred from field name similarity at query time — the system scales to hundreds of entity types without losing precision.

Groundedness metrics become tractable:

Faithfulness: Is every claim in the answer supported by data the agent actually retrieved? Yes — the query result is the sole data source, and it's logged.
ContextPrecision: Did the agent retrieve only relevant context? Yes — schema discovery is demand-driven, not a full dump.

Safety: Access Control at the Data Layer

Agent safety is often discussed in terms of prompt injection and output filtering. Those matter. But the strongest safety posture comes from enforcing access control where the data lives.

When the data infrastructure has its own access control layer — row-level security, field-level permissions, tenant isolation — the agent inherits those constraints automatically. The data layer only returns what the user is authorized to see, regardless of what the agent requests.

This means safety isn't a bolt-on. It's architectural. A support agent querying customer data sees only their assigned accounts — not because the prompt says "only show assigned accounts," but because the data layer enforces row-level filtering before results reach the context window. PII fields are redacted at the source. Fabrication resistance follows naturally: when every answer is a validated query result, the agent is working from real data — not synthesizing from memory.

Trajectory: Guided Navigation vs. Blind Exploration

Trajectory quality asks: did the agent take a good path to the answer? Did it use the right tools in the right order?

Structured infrastructure transforms answering complex questions from open-ended planning into guided navigation. A well-behaved agent follows a predictable pattern:

1. list(type='order')          // what entities are relevant?   ~200 tokens
2. describe(type='order')      // what fields exist?            ~150 tokens
3. related_types(type='order') // how do they connect?
4. validate(query=...)         // catch errors before execution
5. execute(query=...)          // compact result, not raw pages

The trajectory is predictable, short, and auditable. Five tool calls for a complex multi-entity analytical question. And because the pattern is well-defined, deviations from it are measurable:

PlanAdherence: Did the agent follow the discover → relate → query → validate → execute pattern?
StepEfficiency: How many tool calls did it make? Structured approach: typically 4–5 for complex analytical questions.
ToolCorrectness: Did it use the right tools? With a dispatch table, there are only a handful of verbs to choose from. A smaller decision space leads to better choices.

The Dispatch Table Pattern

The key architectural concept here is the dispatch table. Most agent tool designs grow linearly with domain size: one tool per API endpoint, new tools for each new capability, an ever-expanding list of options the agent must choose from. The dispatch table inverts this.

Instead of one tool per endpoint, you expose a small set of generic verbs that dispatch by resource type at runtime. The agent learns four verbs. New domains register type definitions — fields, relationships, valid operations — and the existing verbs work immediately. The tool surface stays flat as capabilities grow.

Endpoint-per-tool (grows with domain):

get_orders()
list_orders()
get_vendors()
list_vendors()
get_contracts()
list_contracts()
search_orders_by_region()
filter_vendors_by_status()
get_sla_breach_count()
...

Dispatch table (stays flat):

list(type='order')
list(type='vendor')
list(type='contract')
 
get(type='vendor', id=...)
describe(type='contract')
execute(query=...)
 
// new domain? register a type.
// no new tools.

Why does this matter for trajectory? A smaller decision space leads to better routing decisions. When the agent must choose from four verbs instead of forty endpoints, it makes fewer wrong turns. The tool descriptions themselves consume less context. And you can test routing exhaustively — the verb space is finite and well-defined.

The dispatch table also creates a clear extension contract. New domains don't negotiate a new API surface with the agent — they register a type definition with declared fields, valid operations, and relationships. The agent's reasoning layer never changes. Only the data model grows.

Performance: Aggregation Belongs at the Data Layer

The context window has a token budget. Every token spent on raw data is a token not available for reasoning.

Structured infrastructure shifts the heavy work — aggregation, joins, filtering — to the data layer. In the running example, the agent receives a compact 6-row table (~800 tokens) instead of processing thousands of raw records. A 10-row aggregation will always be smaller than the 10,000 records it summarizes. This ratio is structural, and it holds regardless of token pricing or context window size.

The design principles follow directly:

Route to the data layer. Every question that can be answered by a server-side query should be. One structured query returning a 10-row table is more efficient than assembling the same answer from multiple API calls.

Schema discovery on demand. Don't load the full ontology upfront. Let the agent introspect the specific types it needs, when it needs them.

Keep the tool surface small. Every tool description consumes context. A dispatch table with generic verbs keeps the footprint flat.

Validate before execute. Don't waste context on executing bad queries and parsing error responses. Catch errors before they consume tokens.

Performance metrics become straightforward:

Latency: One server-side query completes faster than multiple sequential API calls with LLM reasoning between each.
TokenCost: Compact structured results consume a fraction of the context budget compared to raw payloads. Directly measurable, directly attributable to architecture.
CostEfficiency: Correct answer per dollar spent. Structure improves both the numerator (quality) and the denominator (cost).

These Dimensions Reinforce Each Other

These dimensions don't improve independently. They compound.

Better trajectory — fewer, more targeted tool calls — improves performance by reducing context consumption, and improves correctness by keeping less noise in the context. Better groundedness makes safety auditable: you can prove the agent only accessed authorized data because every answer traces to a specific validated query. Better correctness reduces the need for output-layer guardrails, because an agent operating on validated schema data can't fabricate answers that don't exist in the ontology.

This is the core insight: investing in data infrastructure doesn't just improve one dimension of agent quality. It lifts all of them simultaneously, because they all share the same root cause — the agent's ability to operate on structured, validated, well-modeled data instead of raw API noise.

The Investment That Compounds

If you've invested in modeling your enterprise data — a domain ontology, a relationship graph, a query engine, access control at the data layer — you're most of the way to a reliable agent platform. The protocol layer (MCP, tool registration, context formatting) is weeks of work. The data infrastructure is years.

But that investment compounds in a specific way. Every new entity type added to the ontology makes every agent more capable — without changing a line of agent code. Every declared relationship in the graph is a cross-domain question that agents can now answer correctly. Every access control rule at the data layer is a safety guarantee that applies to every agent, every tool, every query.

This investment is real. Ontologies require upfront modeling and ongoing maintenance. Schema evolution — adding fields, changing relationships, deprecating types — needs a migration strategy, the same way a database schema does. Modeling judgment calls are hard: which fields are groupable, which aggregations are meaningful, what cardinality to declare. Not everything needs to be fully modeled — logs, traces, and free-text payloads can't be captured in an ontology. The goal is to model enough of the structural envelope (identifiers, timestamps, categories, relationships) that the ontology becomes the primary routing mechanism for agent queries.

These aren't AI problems. They're data modeling problems. But the organizations that build the most capable agent platforms will be the ones that took them seriously. Not because models aren't powerful — they are. But because well-modeled data infrastructure lets models do what they're best at (reasoning, synthesis, explanation) while the infrastructure handles what it's best at (validation, aggregation, access control, provenance).

The path from data platform to agent platform is shorter than most people think. The quality gap it creates — across correctness, groundedness, safety, trajectory, and performance — is structural. Structure is what makes agents reliable. And it's an investment that keeps paying off.

‍

AI does not just need data. It needs connected context.

This is where I think a lot of engineering leaders are going to have to shift their thinking.

The conversation is often framed around adopting AI tools. But the bigger question is whether your engineering platform is structured in a way that makes AI useful.

If one system knows who owns a service, another knows what was deployed, another knows what failed in production, and none of them are meaningfully connected, then AI is left working with partial information. It may still generate answers, but those answers will be limited by the gaps in the system.

That is why connected platforms matter.

The next generation of AI in engineering will not be powered by isolated tools. It will be powered by systems that connect services, teams, delivery workflows, operational signals, and standards into one usable layer of context.

This is where platform engineering becomes strategic

For years, platform engineering has been framed as a developer productivity initiative. Make it easier to create services. Standardize workflows. Reduce friction. Improve the developer experience.

All of that still matters.

But the rise of AI raises the stakes.

A connected platform is not just a better way to support developers. It is the foundation for giving AI enough context to actually understand how your engineering organization works.

That is why an Internal Developer Portal matters more now than it did even a year ago.

If it is implemented correctly, the portal is not just a front door or a dashboard. It becomes the place where standards, ownership, service metadata, and workflow context come together.

That is what makes it valuable to humans.

And it is also what makes it valuable to AI.

A portal alone is not enough

Of course, none of this works if the portal is static.

A lot of organizations have a portal that shows what services exist and maybe who owns them. But if it is not connected to CI/CD and operational systems, it becomes stale quickly.

That is the difference between a directory and a platform.

CI/CD is where code becomes running software. It is where deployments happen, tests run, policies are enforced, and changes enter production. It is also where some of the most valuable engineering signals are created. Build results, security scans, deployment history, runtime events, and change records all emerge from that flow.

If that evidence stays trapped inside the delivery tooling, the broader platform never reflects reality.

And if the platform does not reflect reality, AI does not have a trustworthy system to reason across.

The real opportunity is a living knowledge layer

When the Internal Developer Portal is connected to CI/CD and fed continuously by operational data, something more important starts to happen.

The platform stops being just a developer interface and starts becoming a living knowledge layer for the engineering organization.

Every service is connected to its owner.

Every deployment is connected to the pipeline that produced it.

Every change event is connected to downstream impact.

Every incident is connected to the affected system and the responsible team.

Every standard and policy is embedded into the same environment where work is actually happening.

That creates a structure AI can work with.

Instead of pulling fragments from disconnected tools, AI can reason across relationships. It can understand not just isolated facts, but how those facts connect across the engineering system.

That is what will separate shallow AI adoption from meaningful AI leverage.

The next generation of AI in engineering will depend on system design

This is why I do not think the future belongs to organizations that simply layer AI on top of fragmented tooling.

It belongs to organizations that create connected platforms first.

Because once the system is connected, AI becomes much more useful. It can surface the right operational context faster. It can help investigate incidents with better awareness of ownership and recent changes. It can support governance by tracing standards and policy state across the delivery flow. It can help teams move faster because it is reasoning inside a connected system rather than guessing across silos.

In other words, the quality of AI outcomes will increasingly depend on the quality of platform design.

That is the bigger shift.

Platform engineering is no longer just about reducing developer friction. It is about building the context layer that modern engineering organizations, and their AI systems, will depend on.

What leaders should do now

The organizations that get ahead here will not start by asking which AI tool to buy.

They will start by asking whether their engineering systems are connected enough to support AI in a meaningful way.

Can you trace a service to its owner, its pipeline, its deployment history, its policy state, and its operational health?

Does your platform reflect what is actually happening in the software delivery lifecycle?

Is your Internal Developer Portal just presenting metadata, or is it becoming the system where engineering context is connected and kept current?

Those are the questions that matter.

Because the next generation of AI in engineering will not be powered by tools alone.

It will be powered by connected platforms that turn engineering activity into usable, trustworthy context.

That is the real opportunity.

Technical

How to Build a Developer Self-Service Platform That Actually Works

Design developer self-service with golden paths, guardrails, and metrics to cut ticket-ops, speed delivery, and keep governance tight.

Bri Strozewski

April 8, 2026

Time to read

Developer self-service works when golden paths, guardrails, and real-time metrics are designed together, so developers can move fast without opening tickets.
A focused 90-day rollout that starts with one or two high-value golden paths lets you prove developer self-service ROI without disrupting existing pipelines.
Policy as code, RBAC, and scorecards keep developer self-service secure and auditable, turning platform engineering from ticket-ops into a measurable product.

Your developers are buried under tickets for environments, pipelines, and infra tweaks, while a small platform team tries to keep up. That is not developer self-service. That is managed frustration.
If 200 developers depend on five platform engineers for every change, you do not have a platform; you have a bottleneck. Velocity drops, burnout rises, and shadow tooling appears.

Developer self-service fixes this, but only when it is treated as a product, not a portal skin. You need opinionated golden paths, automated guardrails, and clear metrics from day one, or you simply move the chaos into a new UI.

Harness Internal Developer Portal turns those ideas into reality with orchestration for complex workflows, policy as code guardrails, and native scorecards that track adoption, standards, and compliance across your engineering org.

What is Developer Self-Service?

Developer self-service is a platform engineering practice where developers independently access, provision, and operate the resources they need through a curated internal developer portal instead of filing tickets and waiting in queues.

In a healthy model, developers choose from well-defined golden paths, trigger automated workflows, and get instant feedback on policy violations, cost impact, and readiness, all inside the same experience.
The portal, your internal developer platform, brings together CI, CD, infrastructure, documentation, and governance so engineers can ship safely without becoming experts in every underlying tool.

If you want a broader framing of platform engineering and self-service, the CNCF’s view on platform engineering and Google’s SRE guidance on eliminating toil are good companions to this approach.

Why Developer Self-Service Matters Now

Developer self-service is quickly becoming the default for high-performing engineering organizations. Teams that adopt it see:

Faster delivery cycles because developers do not wait for centralized teams.
More consistent reliability because standard workflows replace ad hoc one-offs.
Stronger security and compliance because policies run automatically in every workflow.

For developers, that means: less waiting, fewer handoffs, and a single place to discover services, docs, environments, and workflows.

For platform, security, and leadership, it means standardized patterns, visibility across delivery, and a way to scale support without scaling ticket queues.

Choosing the Right Candidates for Developer Self-Service

Not every workflow should be self-service. Start where demand and repeatability intersect.

Good candidates for developer self-service include:

New service scaffolding using approved frameworks and languages.
Environment provisioning for dev, test, and ephemeral preview environments.
Standard infrastructure patterns, such as app plus database stacks or common microservice blueprints.
Routine deployment flows for common applications and services.

Poor candidates are rare, one-time, or highly bespoke efforts, such as major legacy migrations and complex one-off compliance projects. Those stay as guided engagements while you expand the surface area of your developer self-service catalog.

A useful mental model: if a task appears frequently on your team’s Kanban board, it probably belongs in developer self-service.

Core Components of Developer Self-Service

A working developer self-service platform ties three components together: golden paths, guardrails, and metrics.

Golden paths cut decision fatigue and encode your best practices.
Guardrails automate approvals and compliance inside pipelines.
Metrics and scorecards prove that developer self-service is improving outcomes.

When these three live in one place, your internal developer portal, developers get autonomy, and your platform team gets control and visibility.

Golden Paths and Software Catalogs

Developers want to ship code, not reverse engineer your platform. Golden paths give them a paved road.

A strong software catalog and template library should provide:

Searchable entries for services, APIs, libraries, and domains, each with owners and documentation.
Pre-approved templates, such as “Node.js microservice with CI and CD” or “Event-driven service with Kafka,” that plug into your existing tools.
Opinionated defaults for logging, monitoring, security, and testing, so teams start in a good place without extra decisions.

Instead of spending weeks learning how to deploy on your stack, a developer selects a golden path, answers a few questions, and gets a working pipeline and service in hours. The catalog becomes the system of record for your software topology and the front door for developer self-service.

To avoid common design mistakes at this layer, review how teams succeed and fail in our rundown of internal developer portal pitfalls. For additional perspective on golden paths and developer experience, the Thoughtworks Technology Radar often highlights platform engineering and paved road patterns.

Golden paths should also feel fast. Integrating capabilities like Harness Test Intelligence and Incremental Builds into your standard CI templates keeps developer self-service flows quick, so developers are not trading one bottleneck for another.

Policy as Code Guardrails

Manual approvals for every change slow everything to a crawl. Developer self-service requires approvals to live in code, not in email threads.

A practical guardrail model includes:

Policy as Code (for example, with OPA) defines what can run where, under which conditions.
RBAC that controls who can run what, where, and when, aligned with your environments and teams.
Automatic promotion for compliant changes, with only exceptions routed to security or compliance for human review.
Early drift detection and configuration checks that run on every self-service workflow, not just production deploys.

Developers stay in flow because they get instant, actionable feedback in their pipelines. Platform and security teams get a consistent, auditable control plane. That is the sweet spot of developer self-service: autonomy with safety baked in.

On the delivery side, Harness strengthens these guardrails with DevOps pipeline governance and AI-assisted deployment verification, so governance and safety are enforced in every self-service deployment, not just a select few.

If you want to go deeper on policy-as-code concepts, the Open Policy Agent project maintains solid policy design guides that align well with a developer self-service model.

Metrics, Scorecards, and Audit Trails

Developer self-service is only “working” if you can prove it. Your platform should ship with measurement built in, not bolted on later.

Useful scorecards and signals include:

Time to first deploy for new services created through golden paths.
Ticket volume for infra and environment requests before and after self service.
Change failure rate, lead time for changes, and mean time to restore for self-service flows.
Template adoption across teams, mapped against standards and readiness criteria.

Every template execution, pipeline run, and infra change should be tied back to identities, services, and tickets. When leadership asks about ROI, you can show concrete changes: fewer tickets, faster provisioning, higher compliance coverage, all driven by developer self-service.

Harness makes this easier through rich CD and CI analytics and CD visualizations, giving platform teams and executives a unified view of developer self-service performance.

A 90 Day Plan to Launch Developer Self-Service

You do not need a year-long platform program to start seeing value. A structured 90-day rollout lets you move from ticket-ops to real developer self-service without breaking existing CI or CD.

Days 0–30: Lay the Foundation

Pick one application domain (for example, customer-facing web services) and one infrastructure class (for example, Kubernetes).
Define one or two golden paths as software templates that plug into your current CI, CD, and IaC stack.
Connect those templates to infra provisioning workflows, reusing your IaC modules, and add policy as code plus RBAC so compliant requests auto-approve.
Test end-to-end with the platform team first, then invite a single pilot team to validate the developer self-service experience.

Ensure CI pipelines for these golden paths leverage optimizations like Harness Test Intelligence and Incremental Builds, so developers immediately feel the speed benefits.

Days 31–60: Scale and Measure

Expand to three to five templates that cover your most frequent service and infra patterns, incorporating feedback from the first pilot team.
Onboard two or three more teams and move their new services and environment requests onto developer self-service.
Integrate your OPA policies into CI and CD pipelines so that every self-service action is evaluated automatically, and only exceptions require human review.

As usage grows, use Harness Powerful Pipelines to orchestrate more complex delivery flows that still feel simple to developers consuming them through the portal.

Days 61–90: Standardize and Govern

Standardize approval workflows across domains by moving routine decisions into policy code and reserving manual reviews for high-risk or non-standard changes.
Publish documentation, runbooks, and ownership details directly in catalog entries, so developers ask the portal, not Slack, for answers.
Turn on scorecards to track adoption, readiness, and DORA metrics for services onboarded through developer self-service, and use those insights to plan your next wave of templates.

At this stage, many teams widen their rollout based on lessons learned. For an example of how a production-ready platform evolves, see our introduction to Harness IDP.

Governance Without Friction

Governance often fails because it feels invisible until it blocks a deployment. Developer self-service demands the opposite: clear, automated guardrails that are obvious and predictable.

Effective governance for developer self-service looks like this:

Approvals run inside the pipeline as policy as code, not in email or chat.
Golden paths include built-in guardrails, so “doing the right thing” is the simplest choice.
RBAC gates, escape hatches, and non-standard changes to specific roles or senior engineers.
Audit logs capture every self-service action and map it to people, services, and environments.

Developers get fast feedback and clear rules. Security teams focus only on what matters. Auditors get immutable trails without asking platform teams to reassemble history. That is governance that scales with your developer self-service ambitions.

Harness supports this model by combining DevOps pipeline governance with safe rollout strategies such as Deploy Anywhere and AI-assisted deployment verification, so your policies and approvals travel with every deployment your developers trigger.

Developer Self-Service Best Practices

Developer self-service is powerful, but without an opinionated design, it turns into a “choose your own adventure” that nobody trusts. Use these practices to keep your platform healthy:

Treat the platform like a product with clear personas, roadmaps, and feedback channels.
Default to paved, self-service workflows and keep bespoke paths as the exception.
Tie templates to strong observability and SLOs so you can see the impact of your golden paths.
Use scorecards to track standards and production readiness across services, not just adoption.
Iterate with small releases and regular user interviews instead of big bang launches.

The goal is not infinite choice. The goal is a consistent, safe speed for the most common developer journeys.

For more on making portals smarter and more useful, read about the AI Knowledge Agent for internal developer portals. You can also cross-check your direction with Microsoft’s guidance on platform engineering and self-service to ensure your strategy aligns with broader industry patterns.

Ship Faster With Guardrails: Start With Harness IDP

When golden paths, governance, and measurement all come together as one project, developer self-service works. Your platform needs orchestration that links templates to CI, CD, and IaC workflows, policy as code guardrails that automatically approve changes that follow the rules, and a searchable catalog that developers actually use.

When your internal developer portal cuts ticket volume, shrinks environment provisioning from days to minutes, and gives teams clear guardrails instead of guesswork, the ROI is obvious.

If you are ready to launch your first golden path and replace ticket ops with real developer self-service, Harness Internal Developer Portal gives you the orchestration, governance, and insights to do it at enterprise scale.

Developer Self-Service: Frequently Asked Questions (FAQs)

Here are answers to the questions most teams ask when they shift from ticket-based workflows to developer self-service. Use this section to align platform, security, and engineering leaders on what changes, what stays the same, and how to measure success.

How does developer self-service reduce toil without creating chaos?

Instead of making ad hoc requests, developer self-service uses standard workflows and golden paths. Repetitive tasks, like adding new services and environments, turn into catalog actions that always run the same way. Policy as code and RBAC stop changes that aren't safe or compliant before they reach production.

Can we introduce an internal developer portal without disrupting our existing CI or Jenkins setup?

Yes. To begin, put your current Jenkins jobs and CI pipelines into self-service workflows. The portal is the front door for developers, and your current systems are the execution engines that run in the background. You can change or move pipelines over time without changing how developers ask for work.

How do we prove developer self-service ROI and compliance to leadership?

Concentrate on a small number of metrics, such as the number of tickets for infrastructure and environment requests, the time it takes to provision new services and engineers, and the rate of change failure. You can see both business results and proof of compliance in one place when you add policy as code audit logs and scorecards that keep track of standards.

What happens when developers need something outside the standard templates?

"Everything is automated" does not mean "developer self-service." For special cases and senior engineers, make escape hatches that are controlled by RBAC. Let templates handle 80% of the work that happens over and over again. For the other 20%, use clear, controlled processes instead of one-off Slack threads.

How quickly will we see results from a developer self-service rollout?

Most teams see ticket reductions and faster provisioning within the first 30 days of their initial golden path, especially for new services and environments. Onboarding and productivity gains become clear after 60 to 90 days, once new hires and pilot teams are fully using the portal instead of legacy ticket flows.

What tools are essential for a modern developer self-service platform?

You need more than just a UI. Some of the most important parts are an internal developer portal or catalog, CI and CD workflows that work together, infrastructure automation, policy as code, strong RBAC, and scorecards or analytics to track adoption and results. A lot of companies now also add AI-powered search and help to make it easier to learn and safer to use developer self-service.

Technical

How to Implement Self-Service Infrastructure Without Losing Control

Implement self-service infrastructure with automated guardrails. Empower teams, maintain control, and accelerate delivery. Start your journey today.

Bri Strozewski

April 8, 2026

Time to read

What is Self-Service Infrastructure?

Self-service infrastructure allows developers to provision and modify infrastructure without opening tickets or needing deep cloud expertise.

In a mature model:

Developers request environments, services, or resources through an Internal Developer Portal or API.
Requests trigger pipelines that run Terraform/OpenTofu, Kubernetes manifests, and security checks.
Policy as Code enforces security, compliance, and cost controls automatically.
Every action is version-controlled and auditable.

Core Building Blocks of Self-Service Infrastructure

Successful implementations rely on a consistent set of building blocks.

Standardized Templates and Modules

Reusable building blocks for services, environments, and resources, backed by Terraform/OpenTofu modules or Kubernetes manifests. Teams are given a small set of opinionated, well-tested options instead of a blank cloud console.

Guardrails as Code

Security, compliance, and cost policies encoded as code and enforced on every request and deployment. This removes reliance on manual review processes.

Environment Catalog

A defined set of environments (dev, test, staging, production), each with clear policies, quotas, and expectations. The interface remains consistent even if the underlying infrastructure differs.

Internal Developer Portal (IDP)

The control surface for self-service. Developers discover templates, understand standards, and trigger workflows without needing to understand underlying infrastructure complexity.

Harness brings these components together into a single system. The IDP provides the developer experience, while Infrastructure as Code Management and Continuous Delivery execute workflows with governance built in.

Reference Architecture: From Portal to Pipelines to Policy

Once the building blocks are defined, the next step is connecting them into a working system.

A practical architecture looks like this:

Internal Developer Portal as the Front Door

The IDP acts as the control plane for developers. Every self-service action starts here. Developers browse a catalog, select a golden path, and trigger workflows.

Infrastructure as Code Pipelines as the Execution Engine

Workflows trigger pipelines that handle planning, security scanning, approvals, and apply steps for Terraform/OpenTofu or Kubernetes.

Continuous Delivery Pipelines for Promotion

Changes move through environments using structured deployment strategies, with rollback and promotion managed automatically.

Policy as Code Engine for Guardrails

Policies evaluate every request and deployment, blocking non-compliant changes before they reach production.

Scorecards and Dashboards for Visibility

Scorecards aggregate adoption, performance, and compliance metrics across teams and services.

In Harness, this architecture is unified:

The Harness IDP provides catalog, workflows, and scorecards.
Infrastructure as Code Management executes Terraform/OpenTofu with governance and visibility.
Continuous Delivery orchestrates deployments with built-in policy enforcement and verification.

Platform teams define standards once. Developers consume them through self-service.

Governance Without Friction: Guardrails, Not Gates

Governance should not rely on manual approvals. It should be encoded and enforced automatically.

Effective guardrails include:

Policy as Code for security, compliance, and cost controls
Environment-aware RBAC and risk-based approvals
Pre-approved templates for common patterns
Immutable audit logs for every action

The key shift is timing. Checks happen at request time, not days later. Governance becomes proactive instead of reactive.

A 90-Day Playbook for Self-Service Infrastructure

You can demonstrate value quickly by starting small and expanding deliberately.

Phase 1 (Weeks 1–3): Define One Golden Path

Focus on a single high-impact use case.

Select one service type, environment, and region
Define security, networking, and tagging standards
Build one opinionated template with embedded guardrails
Document expected outcomes clearly

The result is a single, high-value workflow that eliminates a significant portion of ticket-driven work.

Phase 2 (Weeks 4–8): Automate Guardrails With Policy-as-Code

Convert manual checks into enforceable rules.

Implement Policy as Code (e.g., Open Policy Agent)
Define rules for tagging, instance types, and regions
Apply environment-specific policies based on risk
Integrate policy checks into pipelines

At this stage, governance is consistently enforced by code.

Phase 3 (Weeks 9–12): Launch Through the IDP and Measure

Expose the golden path through the Internal Developer Portal so developers can discover and execute it independently.

Publish workflows with clear documentation in the IDP
Onboard pilot teams
Track time-to-provision, adoption, and policy outcomes

Use these results to expand to additional services and environments.

Golden Paths and Templates Developers Actually Use

Golden paths determine whether self-service succeeds.

Effective templates:

Hide infrastructure complexity behind safe defaults
Expose only a small number of required inputs
Provide variants for different service types
Include Day 2 operations like monitoring and alerts
Live in a searchable catalog within the IDP

The goal is not full abstraction. It is making the correct path the easiest path.

How CI/CD Fits Into Self-Service Infrastructure

Self-service infrastructure is most effective when integrated with CI and CD.

Continuous Integration

As environments scale, CI must remain efficient.

Harness Continuous Integration supports this with:

Test Intelligence to run only relevant tests
Build insights to identify bottlenecks
Incremental builds to reduce execution time

Continuous Delivery

Continuous Delivery ensures consistent, governed releases.

Harness Continuous Delivery provides:

Deployment strategies such as canary and blue/green
Structured promotion across environments
Policy enforcement within pipelines

This creates a unified path from code to production.

AI-Powered Automation Across the Self-Service Flow

AI can reduce friction across the lifecycle.

Generate pipelines and templates from context
Suggest and refine policy rules
Provide contextual assistance within the IDP
Automate deployment verification and rollback

Harness extends AI across CI, CD, and IDP, enabling faster and more consistent workflows.

Scaling Across Environments and Accounts

Scaling requires consistency and abstraction.

Environment Contracts

Each environment defines:

Standard inputs
Environment-specific policies
Version-controlled configurations

Developers target environments, not infrastructure details.

Abstracting Complexity

Credentials, access, and guardrails are tied to environments.

The IDP presents simple choices, while underlying complexity is managed centrally.

Preventing Drift

Maintain a small set of shared templates
Enforce changes through pipelines
Avoid ad hoc exceptions

This ensures consistency as scale increases.

Measuring ROI and Control With Scorecards

Self-service must be measured, not assumed. A useful scorecard includes:

Developer Velocity

Lead time for changes
Deployment frequency
Mean time to restore

Infrastructure Efficiency

Provisioning time
Resource utilization

Quality and Reliability

Change failure rate
Rollback frequency

Adoption and Compliance

Workflow usage in the IDP
Policy pass rates
Audit completeness

Scorecards live in the IDP, providing a shared view for developers and platform teams.

Autonomy With Guardrails: Your Next 90 Days

Start with a single golden path. Define guardrails. Prove value.

Expose that path through the Harness Internal Developer Portal as the front door to governed self-service, backed by Infrastructure as Code Management, CI, and CD.

Track adoption, speed, and policy outcomes. Use those results to expand systematically.

Self-service infrastructure becomes sustainable when autonomy and governance are built into the same system.

Frequently Asked Questions

How can organizations implement self-service infrastructure without sacrificing security?

Codify policies and enforce them at request and deployment time. Combine this with RBAC and audit logs for full visibility.

What are best practices for governed self-service?

Provide a small set of golden-path templates through an IDP. Keep credentials and policies centralized at the platform level.

What challenges arise when scaling?

Inconsistent environments, template sprawl, and unmanaged exceptions. Standardize inputs and enforce all changes through pipelines.

How do you measure ROI?

Track adoption, delivery speed, and policy outcomes. Use IDP scorecards to connect performance and governance metrics.

What is a realistic rollout timeline?

Approximately 90 days: define one path, automate guardrails, and launch through the IDP.

How does AI impact self-service?

AI accelerates onboarding, policy creation, and deployment validation, reducing manual effort while maintaining control.

Technical

Streamline your Workflows with Environment Management

Harness IDP Environment Management brings full lifecycle control to environments with native CD and IaCM integration.

Bri Strozewski

April 8, 2026

Time to read

We’ve come a long way in how we build and deliver software. Continuous Integration (CI) is automated, Continuous Delivery (CD) is fast, and teams can ship code quickly and often. But environments are still messy.

Shared staging systems break when too many teams deploy at once, while developers wait on infrastructure changes. Test environments get created and forgotten, but over time, what is running in the cloud stops matching what was written in code.

We have made deployments smooth and reliable, but managing environments still feels manual and unpredictable. That gap has quietly become one of the biggest slowdowns in modern software delivery.

This is the hidden bottleneck in platform engineering, and it's a challenge enterprise teams are actively working to solve.

As Steve Day, Enterprise Technology Executive at National Australia Bank, shared:

“As we’ve scaled our engineering focus, removing friction has been critical to delivering better outcomes for our customers and colleagues. Partnering with Harness has helped us give teams self-service access to environments directly within their workflow, so they can move faster and innovate safely, while still meeting the security and governance expectations of a regulated bank.”

At Harness, Environment Management is a first-class capability inside our Internal Developer Portal. It transforms environments from manual, ticket-driven assets into governed, automated systems that are fully integrated with Harness Continuous Delivery and Infrastructure as Code Management (IaCM).

Harness IDP Environment Management List of Available Environments

This is not another self-service workflow. It is environment lifecycle management built directly into the delivery platform.

The result is faster delivery, stronger governance, and lower operational overhead without forcing teams to choose between speed and control.

Closing the Gap Between CD and IaC

Continuous Delivery answers how code gets deployed. Infrastructure as Code defines what infrastructure should look like. But the lifecycle of environments has often lived between the two.

A look at the Harness IDP Environment Management User Journey

Teams stitch together Terraform projects, custom scripts, ticket queues, and informal processes just to create and update environments. Day two operations such as resizing infrastructure, adding services, or modifying dependencies require manual coordination. Ephemeral environments multiply without cleanup. Drift accumulates unnoticed.

The outcome is familiar: slower innovation, rising cloud spend, and increased operational risk.

Environment Management closes this gap by making environments real entities within the Harness platform. Provisioning, deployment, governance, and visibility now operate within a single control plane.

Harness is the only platform that unifies environment lifecycle management, infrastructure provisioning, and application delivery under one governed system.

Blueprint-Driven by Design

At the center of Environment Management are Environment Blueprints.

Platform teams define reusable, standardized templates that describe exactly what an environment contains. A blueprint includes infrastructure resources, application services, dependencies, and configurable inputs such as versions or replica counts. Role-based access control and versioning are embedded directly into the definition.

Harness IDP Environment Management Blueprint

Developers consume these blueprints from the Internal Developer Portal and create production-like environments in minutes. No tickets. No manual stitching between infrastructure and pipelines. No bypassing governance to move faster.

Consistency becomes the default. Governance is built in from the start.

Full Lifecycle Control

Environment Management handles more than initial provisioning.

Infrastructure is provisioned through Harness IaCM. Services are deployed through Harness CD. Updates, modifications, and teardown actions are versioned, auditable, and governed within the same system.

Teams can define time-to-live policies for ephemeral environments so they are automatically destroyed when no longer needed. This reduces environment sprawl and controls cloud costs without slowing experimentation.

Harness EM also introduces drift detection. As environments evolve, unintended changes can occur outside declared infrastructure definitions. Drift detection provides visibility into differences between the blueprint and the running environment, allowing teams to detect issues early and respond appropriately. In regulated industries, this visibility is essential for auditability and compliance.

Harness IDP Environment Management Drift Detection

Governance Built In

For enterprises operating at scale, self-service without control is not viable.

Environment Management leverages Harness’s existing project and organization hierarchy, role-based access control, and policy framework. Platform teams can control who creates environments, which blueprints are available to which teams, and what approvals are required for changes. Every lifecycle action is captured in an audit trail.

This balance between autonomy and oversight is critical. Environment Management delivers that balance. Developers gain speed and independence, while enterprises maintain the governance they require.

"Our goal is to make environment creation a simple, single action for developers so they don't have to worry about underlying parameters or pipelines. By moving away from spinning up individual services and using standardized blueprints to orchestrate complete, production-like environments, we remove significant manual effort while ensuring teams only have control over the environments they own."

— Dinesh Lakkaraju, Senior Principal Software Engineer, Boomi

From Portal to Platform

Environment Management represents a shift in how internal developer platforms are built.

Instead of focusing solely on discoverability or one-off self-service actions, it brings lifecycle control, cost governance, and compliance directly into the developer workflow.

Developers can create environments confidently. Platform engineers can encode standards once and reuse them everywhere. Engineering leaders gain visibility into cost, drift, and deployment velocity across the organization.

Environment sprawl and ticket-driven provisioning do not have to be the norm. With Environment Management, environments become governed systems, not manual processes. And with CD, IaCM, and IDP working together, Harness is turning environment control into a core platform capability instead of an afterthought.

This is what real environment management should look like.

‍

Technical

AI for GitOps: Tame your Argo Sprawl

Harness AI for GitOps enables conversational control, automating troubleshooting, orchestration, and config management to reduce toil and speed up delivery.

Eric Minick

April 6, 2026

Time to read

Innovation is moving faster than ever, but software delivery has become the ultimate chokepoint. While AI coding assistants have flooded our repositories with an unprecedented volume of code, the teams responsible for actually delivering that code, our Platform and DevOps engineers, are often left drowning in manual toil.

If you’re managing Argo CD at an enterprise scale, you’re painfully familiar with the "Day 2" reality. It can become tab fatigue as a service: jumping between dozens of instances, chasing out-of-sync applications, and manually diffing YAML just to figure out where your configuration drifted.

Today, we are thrilled to introduce AI for Harness GitOps. It’s an agentic intelligence layer designed to help you manage, monitor, and troubleshoot your entire GitOps estate through simple, natural language.

From "ClickOps" to Conversational Control

Standard GitOps tools are excellent at syncing state, but they often lack the high-level orchestration required by complex enterprises. When an application goes out of sync, you shouldn't have to click through multiple tabs and clusters just to find out why.

With AI for GitOps, Harness brings a new level of context-aware, agentic intelligence to your delivery lifecycle:

Fleet-Wide Troubleshooting: Imagine asking, "I have four out-of-sync apps; are they out of sync for the same reason?" Instead of checking each one manually, the Harness DevOps Agent researches the resource trees across your clusters, identifies a common Kustomization CRD issue, and provides a resolution in seconds.
Agentic Configuration Management: The AI doesn't just read data; it acts on it. You can now manage the configuration of GitOps applications and Harness resources directly.
Intelligent Workflow Orchestration: The AI can now modify and optimize the Harness Pipelines that surround your GitOps activities. If a deployment pattern is consistently failing due to timeout issues, you can instruct the agent to "Adjust the orchestration logic in the deployment pipeline to include an automated verification gate" and increase the health check timeout.
Deep-Dive Diagnostics: Instantly retrieve container logs, track deployment events, and map resource dependencies using natural language prompts.

Why This Matters for the Enterprise

We built this because scaling GitOps shouldn't mean scaling your headcount. Our mission is to provide an Enterprise Control Plane that enhances your existing Argo investment rather than replacing it.

1. Eliminate "Day 2" Toil

Platform engineering teams are often overwhelmed and understaffed. By moving from manual root cause analysis to automated reasoning and active configuration management, we free up engineers to focus on innovation rather than repetitive maintenance tasks.

2. Accelerate MTTR

By leveraging the Harness Software Delivery Knowledge Graph, our AI understands your unique workflows, policies, and ecosystem. It doesn't just show you an error; it explains it in the context of your specific environment and can proactively suggest (or execute) the configuration changes needed to resolve the issue. The goal here is to move the needle on Mean Time to Recovery (MTTR) from hours to minutes.

3. Governance at Speed

Here’s the thing: speed without safety is just a faster way to break things, and work more nights and weekends fixing them. Harness ensures that enterprise-grade governance is built in, not bolted on. Every AI-driven action, including configuration updates and pipeline modifications, is governed by your existing RBAC and OPA (Open Policy Agent) policies, providing an immutable audit trail for every change.

Bottom Line: Ship Faster & Safer with AI

The promise of AI for developers has been held back by the limitations of the deployment pipeline. Harness AI for GitOps bridges that gap, providing a "prompt-to-production" workflow that is finally as fast as the code being written.

Simply put, it's time to stop syncing and start orchestrating. Experience the future of intelligent delivery with Harness.

Want to see it live? Get a demo.

Technical

Ansible vs Terraform Explained: Key Differences for Modern Infrastructure Automation

Compare Ansible and Terraform: when to use each, how to combine them in GitOps/CI/CD, and best practices for secure, scalable automation.

Mrinalini Sugosh

April 6, 2026

Time to read

Ansible and Terraform work well together. Terraform is best for setting up and managing infrastructure, while Ansible is great for configuration, orchestration, and ongoing operations.
Using Ansible and Terraform together in managed GitOps workflows helps enterprise teams automate infrastructure at scale, keep records for audits, and meet compliance needs. This approach also removes manual steps and reduces configuration drift.
Harness Continuous Delivery & GitOps offers a single, AI-powered control panel that manages both Terraform and Ansible. It brings together governance, visibility, and policy enforcement for complex deployment pipelines.

If DevOps teams mix up the roles of Ansible and Terraform, deployment pipelines can become unreliable. Manual handoffs slow down changes, and audits may find gaps where responsibilities overlap. Each tool solves different problems, so using them correctly avoids delays and compliance risks.

Are you dealing with scattered provisioning and configuration workflows? Harness Continuous Delivery offers an AI-powered control panel that manages both Terraform and Ansible, giving you unified visibility and policy enforcement.

Ansible vs Terraform: Core Concepts, Strengths, and Trade-Offs

Understanding the differences between Ansible and Terraform starts with recognizing that they solve complementary layers of infrastructure automation. Terraform excels at declaring and managing cloud resources, while Ansible shines at configuring the workloads that run on that infrastructure. Both tools are agentless and complement each other, but their architectural approaches and state-management philosophies yield distinct strengths and limitations.

Concern	Terraform	Ansible	When to use
Model	Declarative HCL, stateful	Imperative tasks / idempotent modules	Provision infra vs configure & runbooks
State management	Stores state, plan/apply	No central state (inventory only)	Terraform for lifecycle; Ansible for Day-2
Drift detection	Built in via plan & state	External/ops-driven	Terraform for detecting infra drift
Scale & governance	Workspaces, remote backends, modules	AWX/Tower/AAP for orchestration	Terraform for infra at scale; Ansible for fleet ops
Secrets	Remote backends, Vault integration	Ansible Vault, external secret managers	Use secrets management for both

Terraform: Declarative Provisioning and Lifecycle Management

Terraform specializes in infrastructure provisioning through declarative HashiCorp Configuration Language (HCL). It maintains a state file that tracks every resource it provisions, enabling planned changes and drift detection.

This stateful approach makes Terraform ideal for managing cloud resources like VPCs, databases, and Kubernetes clusters across multiple providers. Research shows Terraform's immutable infrastructure philosophy, replacing rather than modifying resources, reduces configuration drift and improves reproducibility at scale.

Ansible: Agentless Configuration and Orchestration

While Terraform sets up infrastructure, Ansible uses a task-based method with easy-to-read YAML playbooks run over SSH. Ansible does not keep a persistent state. Instead, it uses idempotent modules that give the same results no matter how many times you run them.

This makes Ansible a strong choice for configuring operating systems, deploying applications, and handling ongoing maintenance after the first setup. Studies describe Ansible as a tool for making changes directly on servers, which is useful for managing many machines at once.

State Management: Plans vs Push-Based Execution

The main difference between these tools is how they manage state. Terraform’s state file is the main record, letting you preview changes before making them. This setup helps detect drift and allows rollbacks using Infrastructure as Code tools.

On the other hand, Ansible sends configurations straight to target systems using idempotent tasks. This makes setup easier at first, but you need other ways to prevent drift and check changes in large environments.

Enterprise Scale: Governance and Visibility Matter

For large organizations, choosing the right tool is less important than having good governance and visibility. Using policy-as-code frameworks like Open Policy Agent, keeping audit trails, and using templates for consistency are all key.

Modern platforms provide GitOps control planes that orchestrate both Terraform provisioning and Ansible configuration within governed workflows, ensuring compliance without blocking developer productivity.

When to Choose Terraform for Provisioning at Scale

Terraform is best when you need to manage infrastructure across many cloud providers, environments, and teams. For large organizations with hundreds of services, using Terraform at scale helps ensure reliable and trackable infrastructure delivery.

Set up cloud resources using Terraform’s plan-and-apply workflow. You can manage identity systems, VPCs, databases, Kubernetes clusters, and storage across AWS, Azure, and GCP. Any resource with an API can be managed as code.
Enforce reusable standards through Terraform modules and registries that codify your organization's networking patterns, security baselines, and compliance requirements, preventing configuration drift across teams and regions.
Organize workspaces by environment and team boundaries, following workspace best practices like separating stateful resources (databases) from volatile ones (compute) to minimize blast radius and enable safe parallel development.
Use policy-as-code tools like OPA or Sentinel to automatically check resource settings, costs, and security before making any changes to production.
Set up remote state management and deployment pipelines to track every infrastructure change from development to production. This creates permanent audit trails for compliance teams.
Coordinate complex releases by integrating Terraform provisioning with GitOps workflows that can automatically create ephemeral environments, run verification tests, and promote successful changes across your infrastructure.

Ansible and Terraform Together in GitOps and CI/CD (2026 Best Practices)

The question of whether Ansible and Terraform can be used together has a clear answer: they work best as complementary layers in modern delivery pipelines. Define your cloud infrastructure with Terraform, then configure and orchestrate with Ansible, tying both to Git repositories and promotion workflows to reduce drift and manual handoffs. Terraform actions now support direct integration, enabling a single Terraform apply to dispatch Ansible Event-Driven Automation workflows while keeping inventories synchronized across both tools.

In practice, this setup works best when you use GitOps controllers like ArgoCD to deliver Kubernetes applications, while Terraform manages the clusters and cloud resources underneath.

This separation makes roles clear: Terraform sets up what you need, GitOps delivers your applications, and Ansible takes care of node setup, runbooks, and ongoing tasks that aren’t covered by Kubernetes.

For large organizations, centralize visibility and governance by using golden-path templates, OPA policy checks, and release management. This reduces manual work and helps keep compliance consistent.

Modern platforms solve Argo sprawl by offering a single control panel for managing multi-stage releases, enforcing policy-as-code, and keeping audit trails across all deployments. This helps teams deliver faster while keeping the governance needed for complex, regulated environments.

FAQ: Ansible vs Terraform for Enterprise DevOps Workflows

Enterprise teams managing hundreds of services often face complex decisions about when to use automated infrastructure setup versus hands-on system configuration. These frequently asked questions address practical concerns about combining both approaches while maintaining governance and visibility at scale.

What are the main differences between Ansible and Terraform for enterprise DevOps workflows?

Terraform excels at declarative infrastructure provisioning with state management and drift detection, making it ideal for cloud resources and lifecycle management. Ansible specializes in imperative system configuration, application deployment, and orchestration tasks across existing infrastructure. Air France-KLM successfully combined both, using Terraform for provisioning and Ansible for post-deployment setup, scaling to 7,200 workspaces supporting 450+ teams.

How do Ansible and Terraform compare for automating cloud infrastructure in 2026?

Terraform leads infrastructure provisioning with its declarative model and comprehensive cloud provider support, while Ansible remains the preferred choice for system configuration and Day 2 operations.

Which tool is better for CI/CD pipeline automation: Ansible or Terraform?

Both tools serve different pipeline stages rather than competing directly. Terraform handles infrastructure provisioning steps, while Ansible manages application setup and deployment tasks. Modern CI/CD platforms orchestrate both tools within unified pipelines, using failure strategies and conditional logic to coordinate Terraform applies followed by Ansible configuration runs based on environment and deployment context.

Can Ansible and Terraform be used together for scalable infrastructure management?

Yes, they work exceptionally well together. Enterprise teams typically use Terraform for infrastructure provisioning with S3-backed state management, followed by Ansible for OS setup and application installation. This separation of concerns enables teams to leverage each tool's strengths while maintaining clear boundaries between infrastructure lifecycle and system configuration responsibilities.

How should teams handle state, idempotence, and drift when combining Ansible and Terraform?

Terraform manages infrastructure state through remote backends with drift detection, while Ansible ensures idempotent system setup through declarative playbooks. Teams should establish clear ownership boundaries, use Terraform for stateful cloud resources, and leverage Ansible for application configuration that doesn't require persistent state tracking. Centralized GitOps platforms provide unified visibility across both tools' operations and drift detection.

What governance and compliance practices help standardize changes across 25+ clusters and 50+ repos?

Implement Policy as Code using Open Policy Agent (OPA) to enforce guardrails across both Terraform and Ansible workflows. Pre-written policy sets for compliance frameworks like NIST SP 800-53 accelerate adoption. Centralize policy management, use template-based approaches for consistency, and integrate policy checks into CI/CD pipelines to catch violations before deployment across distributed infrastructure.

From Tools to Outcomes: Standardize with Golden Paths and Governed GitOps

Choosing between Ansible and Terraform becomes simpler when you focus on outcomes rather than tools. Create golden-path templates that codify your Terraform provisioning and Ansible configuration processes together. Enforce OPA policies at every stage to maintain compliance without blocking developer velocity.

Meaningful scale happens when you centralize GitOps visibility to eliminate Argo sprawl across your infrastructure. Use AI to generate pipelines from natural language and automatically verify deployments with intelligent rollback capabilities. Start with one service, establish your workflow patterns, then propagate templates across all environments with automated governance that scales with your team.

Ready to move beyond manual pipeline creation and fragmented GitOps management? Harness Continuous Delivery transforms your Terraform and Ansible pipelines into AI-powered, policy-governed systems that deliver software faster and more securely.

Technical

The pipeline that never reached production

How to improve CI/CD governance using template-driven pipelines, Git controls, and policy enforcement to protect production.

Anmol Pandey

Stefano Mazzone

April 2, 2026

Time to read

How template-driven CD prevents governance drift

Modern CI/CD platforms allow engineering teams to ship software faster than ever before.

Pipelines complete in minutes. Deployments that once required carefully coordinated release windows now happen dozens of times per day. Platform engineering teams have succeeded in giving developers unprecedented autonomy, enabling them to build, test, and deploy their services with remarkable speed.

Yet in highly regulated environments-especially in the financial services sector-speed alone cannot be the objective.

Control matters. Consistency matters. And perhaps most importantly, auditability matters.

In these environments, the real measure of a successful delivery platform is not only how quickly code moves through a pipeline. It is also how reliably the platform ensures that production changes are controlled, traceable, and compliant with governance standards.

Sometimes the most successful deployment pipeline is the one that never reaches production.

This is the story of how one enterprise platform team redesigned their delivery architecture to ensure that production pipelines remained governed, auditable, and secure by design.

The subtle risk in fast CI/CD platforms

A large financial institution had successfully adopted Harness for CI and CD across multiple engineering teams.

From a delivery perspective, the transformation looked extremely successful. Developers were productive, teams could create pipelines quickly, and deployments flowed smoothly through various non-production environments used for integration testing and validation. From the outside, the platform appeared healthy and efficient.

But during a platform architecture review, a deceptively simple question surfaced:

“What prevents someone from modifying a production pipeline directly?”

There had been no incidents. No production outages had been traced back to pipeline misconfiguration. No alarms had been raised by security or audit teams.

However, when the platform engineers examined the system more closely, they realized something concerning.

Production pipelines could still be modified manually.

In practice this meant governance relied largely on process discipline rather than platform enforcement. Engineers were expected to follow the right process, but the platform itself did not technically prevent deviations. In regulated industries, that is a risky place to be.

The architecture shift: separate authoring from execution

The platform team at the financial institution decided to rethink the delivery architecture entirely. Their redesign was guided by a simple but powerful principle:

Pipelines should be authored in a non-prod organization and executed in the production organization. And, if additional segregation was needed due to compliance, the team could decide to split into two separate accounts.

Authoring and experimentation should happen in a safe environment. Execution should occur in a controlled one.

Instead of creating additional tenants or separate accounts, the platform team decided to go with a dedicated non-prod organization within the same Harness account. This organization effectively acted as a staging environment for pipeline design and validation.

Architecture diagram

This separation introduced a clear lifecycle for pipeline evolution.

The non-prod organization became the staging environment where pipeline templates could be developed, tested, and refined. Engineers could experiment safely without impacting production governance.

The production organization, by contrast, became an execution environment. Pipelines there were not designed or modified freely. They were consumed from approved templates.

Guardrail #1: production pipelines must use templates

The first guardrail introduced by the platform team was straightforward but powerful.

Production pipelines must always be created from account-level templates.

Handcrafted pipelines were no longer allowed. Project-level template shortcuts were also prohibited, ensuring that governance could not be bypassed unintentionally.

This rule was enforced directly through OPA policies in Harness.

Example policy

package harness.cicd.pipeline

deny[msg] {
  template_scope := input.pipeline.template.scope
  template_scope != "account"
  msg = "pipeline can only be created from account level pipeline template"
}

This policy ensured that production pipelines were standardized by design. Engineers could not create or modify arbitrary pipelines inside the production organization. Instead, they were required to build pipelines by selecting from approved templates that had been validated by the platform team.

As a result, production pipelines ceased to be ad-hoc configurations. They became governed platform artifacts.

Guardrail #2: governance starts in the non-prod organization

Blocking unsafe pipelines in production was only part of the solution.

The platform team realized it would be even more effective to prevent non-compliant pipelines earlier in the lifecycle.

To accomplish this, they implemented structural guardrails within the non-prod organization used for pipeline staging. Templates could not even be saved unless they satisfied specific structural requirements defined by policy.

For example, templates were required to include mandatory stages, compliance checkpoints, and evidence collection steps necessary for audit traceability.

Example policy

package harness.ci_cd

deny[msg] {
  input.templates[_].stages == null
  msg = "Template must have necessary stages defined"
}

deny[msg] {
  some i
  stages := input.templates[i].stages
  stages == [Evidence_Collection]
  msg = "Template must have necessary stages defined"
}

These guardrails ensured that every template contained required compliance stages such as Evidence Collection, making it impossible for teams to bypass mandatory governance steps during pipeline design.

Governance, in other words, became embedded directly into the pipeline architecture itself.

The source of truth: Git

The next question the platform team addressed was where the canonical version of pipeline templates should reside.

The answer was clear: Git must become the source of truth.

Every template intended for production usage lived inside a repository where the main branch represented the official release line.

Direct pushes to the main branch were blocked. All changes required pull requests, and pull requests themselves were subject to approval workflows that mirrored enterprise change management practices.

Governance flow

This model introduced peer review, immutable change history, and a clear traceability chain connecting pipeline changes to formal change management records.

For auditors and platform leaders alike, this was a significant improvement.

The promotion workflow

Once governance mechanisms were in place, the promotion workflow itself became predictable and repeatable.

Engineers first authored and validated templates within the non-prod organization used for pipeline staging. There they could test pipelines using real deployments in controlled non-production environments.

The typical delivery flow followed a familiar sequence:

After validation, the template definition was committed to Git through a branch and promoted through a pull request. Required approvals ensured that platform engineers, security teams, and change management authorities could review the change before it reached the release line.

Once merged into main, the approved template became available for pipelines running in the production organization. Platform administrators ensured that naming conventions and version identifiers remained consistent so that teams consuming the template could easily track its evolution.

Finally, product teams created their production pipelines simply by selecting the approved template. Any attempt to bypass the template mechanism was automatically rejected by policy enforcement

The day the model proved its value

Several months after the new architecture had been implemented, an engineer attempted to modify a deployment pipeline directly inside the production organization.

Under the previous architecture, that change would have succeeded immediately.

But now the platform rejected it. The pipeline violated the OPA rule because it was not created from an approved account-level template.

Instead of modifying the pipeline directly, the engineer followed the intended process: updating the template within the non-prod organization, submitting a pull request, obtaining the necessary approvals, merging the change to Git main, and then consuming the updated template in production.

The system had behaved exactly as intended. It prevented uncontrolled change in production.

Why this model works

The architecture introduced by the large financial institution delivered several key guarantees.

Production pipelines are standardized because they originate only from platform-approved templates. Governance is preserved because Git main serves as the official release line for pipeline definitions. Auditability improves dramatically because every pipeline change can be traced back to a pull request and associated change management approval. Finally, platform administrators retain the ability to control how templates evolve and how they are consumed in production environments.

The lesson for platform teams

Pipelines are often treated as simple automation scripts.

In reality they represent critical production infrastructure.

They define how code moves through the delivery system, how security scans are executed, how compliance evidence is collected, and ultimately how deployments reach production environments. If pipeline creation is uncontrolled, the entire delivery system becomes fragile.

The financial institution solved this problem with a remarkably simple model. Pipelines are built in the non-prod staging organization. Templates are promoted through Git governance workflows. Production pipelines consume those approved templates.

Nothing more. Nothing less.

Final takeaway

Modern CI/CD platforms have dramatically accelerated the speed of software delivery.

But in regulated environments, the true achievement lies elsewhere. It lies in building a platform where developers move quickly, security remains embedded within the delivery workflow, governance is enforced automatically, and production environments remain protected from uncontrolled change.

That is not just CI/CD. That is platform engineering done right.

Technical

Agentic Coding And The New Role Of Internal Developer Portals

Discover how agentic coding and Internal Developer Portals work together to safely automate software delivery with AI-driven workflows and guardrails.

Bri Strozewski

April 2, 2026

Time to read

Agentic coding turns AI from fancy autocomplete into something closer to a junior engineer — one that can plan work, execute it, run tests, debug failures, and iterate, all using your actual tools and environments.
Internal Developer Portals (IDPs) become the control plane that gives those agents the map, the rules, and the guardrails they need to work safely at scale.
Getting “agent-ready” isn’t about buying the shiniest new tool. It’s about having trustworthy metadata, standardized golden paths, executable policies, and programmatic access to your platform capabilities. A pretty portal UI alone won’t cut it.

Here’s the thing about agentic coding: it’s what happens when AI stops suggesting code and starts doing the work. You describe a high-level goal — something like “add email verification to user signup” — and an AI agent takes it from there. It plans the approach, digs through the repo, edits files, runs tests, debugs what breaks, and keeps going until the job is done. You’re not approving one autocomplete suggestion at a time anymore. You’re supervising an autonomous workflow that’s plugged into your actual CI pipelines, your docs, your tickets, your environments.

That kind of autonomy can’t run on top of chaos. It needs a structured, trusted surface where services, workflows, and policies are laid out clearly. And that’s exactly where the Internal Developer Portal stops being “a catalog and some links” and starts acting as the control plane for both humans and agents.

If you want that control plane today, Harness Internal Developer Portal gives you the service catalog, golden paths, policies, and orchestration layer you need to adopt agentic coding without losing sleep.

What Does Agentic Coding Actually Look Like?

Traditional AI-assisted coding is reactive. You write a prompt, it completes the line, and you stay firmly in the driver’s seat.

Agentic coding flips that dynamic. The industry is converging on a few defining traits:

You give the agent a goal, not a line of code. Something like: “Implement user signup with email verification.”

From there, the agent explores your codebase, reads documentation, and puts together a plan. It edits or creates files, runs tests, and if something breaks, it debugs. It keeps looping through that cycle until the goal is met — or until guardrails tell it to stop.

The big shift here is autonomy combined with tool use. These agents are wired into your repo, your CI pipelines, your docs, your ticketing system — sometimes even your infrastructure. They decide what to do next based on outcomes, much like a junior engineer working through a ticket queue.

Why Agentic Coding Needs An Internal Developer Portal

Here’s something anyone who’s managed a team already knows: people do their best work in structured environments. They struggle in ambiguous ones. Agents are no different.

The major cloud and security vendors are all saying the same thing: agentic systems work best when they have well-defined tools, schemas, and policies to operate within. An IDP provides exactly that structure.

The service catalog becomes the map.

Ownership, dependencies, environments, APIs, lifecycle stage, repo links — it’s all there. When an agent changes a shared library, it can actually reason about which downstream services might be affected. Without that metadata? You’re flying blind.

Workflows and golden paths keep agents on the rails.

CI/CD pipelines, infra provisioning, incident playbooks, and compliance checks — in Harness, these are defined as reusable platform flows. Agents trigger the approved flows instead of improvising their own, which is how you keep actions compliant and predictable.

Policy and governance become executable, not just documented.

OPA policies, RBAC, freeze windows, required checks — they become rules the system enforces automatically. This matters because agents don’t “remember” tribal knowledge. They run code. If the rule isn’t encoded, it doesn’t exist to them.

Put it all together, and the portal becomes both the system of record and the operations surface. Humans click buttons or fill out forms. Agents call the same flows through APIs. Same guardrails, same audit trail, different interface.

New Capabilities — And New Risks — For Platform Teams

Once agents can act through an IDP, some genuinely useful workflows open up.

Environment provisioning is a natural fit.

An agent reads environment templates from the portal, fills in the parameters, spins up a new sandbox or preview environment, and registers it back into the catalog. No tickets, no waiting.

Routine deployments work well too — at least for low-risk services with strong test coverage and solid observability.

An agent can promote builds along a golden path, run automated checks, and roll back if anomaly detection flags something. Harness’s delivery platform already supports this kind of automated pipeline orchestration.

Dependency impact analysis is where things get really interesting.

Before upgrading a shared library, the agent queries the catalog for dependents, opens PRs across those services, runs pipeline checks, and reports back with results. That’s hours of toil, automated.

But let’s be honest about the risks, too. Every serious security analysis of agentic coding points to the same concerns:

Scaled errors are the big one. A misconfigured agent can update dozens of services in minutes. If your templates and policies are optional — just suggestions that people (and now agents) can ignore — the agent will amplify every inconsistency in your system.
Configuration drift sneaks in when agents bypass golden paths and call underlying tools directly. Your carefully designed “standards” become more like… suggestions.
Security and compliance gaps emerge when you can’t prove what an agent did and why. In regulated environments, that’s a dealbreaker.

Harness IDP addresses these risks with enforced templates, auditable workflows, drift detection, OPA policies, and granular RBAC. Each agent identity only touches what it’s explicitly allowed to — same as you’d scope permissions for any engineer.

An Agentic Coding Maturity Model For Your Portal

Nobody goes from “we have a portal” to “AI is co-piloting our delivery” overnight. And honestly, trying to skip steps is how you end up with agents making a mess. Maturity matters more than the shiny new feature.

Here’s a practical way to think about the journey:

Stage 0: Portal As Brochure.

The service catalog is incomplete. Templates are optional. Workflows live in wikis and docs rather than automation. If you let an agent loose at this stage, it’s going to expose every gap you’ve been meaning to fix.

Stage 1: Trusted Metadata.

Every service has clear ownership, lifecycle status, environments, and repo links. The catalog is accurate, and people actually maintain it. This is where humans benefit first — and agents will benefit later.

Stage 2: Standardized Golden Paths.

You’ve built production-ready templates for your common service types, with CI, observability, security, and infra defaults baked in. Both developers and agents start from these paths, not from scratch.

Stage 3: Executable Guardrails.

Policies for licenses, infra validation, PII handling, and deployment checks are encoded directly into your CI and portal workflows. Gates fire automatically — nobody needs to “remember” them.

Stage 4: AI-Governed Control Plane.

The IDP is a unified control plane for humans and agents alike. Every capability can be invoked programmatically. Autonomy levels are tuned based on incident reviews and audits. This is where agentic coding really shines.

Harness IDP is designed to help teams move along this curve — from organizing metadata, to defining golden paths, to enforcing policy-as-code, and finally to safely plugging in agents.

Getting Agent-Ready In The Next 6–12 Months

If you want to be running agentic coding workflows on top of your IDP within a year, work backwards from what agents actually need.

On the technical side:

Clean up your service catalog and make it your source of truth. If the metadata is stale or incomplete, agents will make bad decisions based on bad data.

Wrap your core platform operations in reusable flows and templates instead of one-off scripts. Agents need repeatable, well-defined actions to call — not artisanal shell scripts that only one person understands.

Encode your key policies into CI and portal workflows so they run on every relevant change. If a check matters, automate it.

On the cultural side:

Treat agents like junior engineers, not magic. They need code review, bounded scopes, and feedback loops — just like any new hire.

Establish clear ownership for portal data quality. If nobody owns the metadata, the agent’s output will be just as fuzzy.

On the process side:

Start small. Pick narrow, low-risk workflows like preview environment creation or doc updates. Let the team build confidence.

Measure impact with straightforward DevEx metrics: how long do developers wait for environments? What’s your time-to-merge? Deployment success rates?

Expand agent scope gradually — only where guardrails and signal quality are genuinely strong.

The end result is an IDP that can safely host agentic coding experiments without turning your platform into a free-for-all.

Turn Your IDP Into An Agentic Control Plane

Agentic coding is already reshaping how software gets built. The question isn’t whether agents will touch your delivery workflows — they will. The real question is whether they’ll operate inside a governed control plane or out on the edges of your tooling where nobody’s watching.

An Internal Developer Portal that works as a real control plane — not just a dashboard — is how you keep humans productive and agents accountable. Harness IDP gives you that: trusted metadata, golden paths, executable policies, and platform flows that work for human clicks and agent API calls alike.

Book a demo with Harness and see how it works in practice.

Agentic Coding FAQ

What is agentic coding?

Agentic coding is AI-assisted development where an autonomous agent plans, executes, and iterates on multi-step coding tasks using your real tools and environments. Think of it less like autocomplete and more like handing a well-scoped ticket to a junior engineer who happens to work very, very fast.

How is agentic coding different from traditional AI code assistants?

Traditional assistants respond to each prompt in isolation — you stay in tight control the whole time. With agentic coding, the AI pursues a goal end-to-end: editing files, running tests, interpreting results, and making follow-up decisions on its own. You supervise rather than micromanage.

Why does agentic coding need an Internal Developer Portal?

Because agents need accurate metadata, standardized workflows, and encoded policies to act safely. An IDP provides that structured map of services, environments, and golden paths that agents can actually navigate and operate within. Without it, you’re giving an autonomous system the keys to a disorganized house.

What are the main risks of agentic coding?

The biggest concerns are scaled mistakes (one bad config propagated across dozens of services), configuration drift (agents bypassing your golden paths), and security gaps (lack of audit trails and policy enforcement). These risks grow fast in complex or regulated environments.

How can Harness help teams adopt agentic coding safely?

Harness Internal Developer Portal centralizes service metadata, enforces golden paths and policy-as-code, and exposes reusable platform flows. Together, these create the guardrails and observability you need to introduce agentic coding with confidence rather than anxiety.

Technical

Introducing Zero Trust Architecture for Software Delivery

Move beyond RBAC and gates. Discover how to create a "last line of defense" for your SDLC by validating every automated task at the runner level.

Eric Minick

Pranay Kaikini

April 2, 2026

Time to read

For the world’s largest financial institutions, places like Citi and National Australia Bank, shipping code fast is just part of the job. But at that scale, speed is nothing without a rock-solid security foundation. It’s the non-negotiable starting point for every release.

Most Harness users believe they are fully covered by our fine-grained Role-Based Access Control (RBAC) and Open Policy Agent (OPA). These are critical layers, but they share a common assumption: they trust the user or the process once the initial criteria are met. If you let someone control and execute a shell script, you’ve trusted them to a great extent.

But what happens when the person with the "right" permissions decides to go rogue? Or when a compromised account attempts to inject a malicious script into a trusted pipeline?

Harness is changing the security paradigm by moving beyond Policy as Code to a true Zero Trust model for your delivery infrastructure.

The Challenge: When Permissions Aren't Enough

Traditional security models focus on the "Front Door." Once an employee is authenticated and their role is verified, the system trusts their actions. In a modern CI/CD environment, this means an engineer with "Edit" and "Execute" rights can potentially run arbitrary scripts on your infrastructure.

If that employee goes rogue or their credentials are stolen, RBAC won't stop them. OPA can control whether shell scripts are allowed at all, but it often struggles to parse the intent of a custom shell script in real-time.

The reality is that verify-at-the-door is a legacy mindset. We need to verify at execution time. CI/CD platforms are a supply-chain target that are often targeted. The recent attack against the Checkmarx GitHub Action has been a painful reminder of the lesson the Solarwinds fiasco should have taught the industry.

Introducing Harness Zero Trust

Harness Zero Trust is a new architectural layer that acts as a mandatory "interruption" service at the most critical point: the Harness Delegate (our lightweight runner in your infrastructure).

Instead of the Delegate simply executing tasks authorized by the control plane, it now operates on a "Never Trust, Always Verify" basis.

How It Works: The Final Line of Defense

When Zero Trust is enabled, the Harness Delegate pauses before executing any task. It sends the full execution context to a Zero Trust Validator, a service hosted and controlled by your security team.

This context includes:

User Identity: Who triggered the action?
Task Specifics: Exactly what is the Delegate being asked to do?
Script Content: The full body of any shell scripts.
Environment Variables: The inputs and secrets being injected into the task.

The Delegate waits a moment. Only if the validator returns a "True" signal does the task proceed. If the signal is "False," the execution is killed instantly.

Why This Matters for Enterprise DevSecOps

By moving validation to the Delegate level, we provide a "Last Line of Defense" that hits several key enterprise requirements:

Rogue Employee Protection: Even if a user has the rights to run a pipeline, your security service can flag suspicious patterns (like a script attempting to delete a production database or exfiltrate data) and stop it before it starts.
Architectural Superiority: While competitors struggle with stability and baseline security, Harness is doubling down on a hardened architecture. RBAC protects the door; OPA governs the "what"; and Zero Trust validates the "how."
Custom Judgement: Because Harness sends the complete task details, you can point this validator at a customer algorithm or an AI-powered security tool to judge the "safety" of scripts in real-time. Essentially, you are peer-reviewing every line of automation at execution time.

The Takeaway

We built this capability alongside some of the world's most regulated institutions to ensure it doesn't become a bottleneck. It’s designed to be a silent guardian. It shuts down the 1% of rogue actions while the other 99% of your engineers continue to innovate at high velocity.

The bottom line: at Harness, we believe that the promise of AI-accelerated coding must be met with an equally advanced delivery safety net. We’re building out that safety net every day. Zero Trust is the next piece.

Technical

Defeating Context Rot: Mastering the Flow of AI Sessions

AI agents fail due to context rot—growing context degrades accuracy. Use plan, execute, reset, and checkpoints to keep outputs consistent and reliable.

Dewan Ahmed

Shreyas Nagaraj

April 1, 2026

Time to read

In Part 1, we argued that most dev teams start in the wrong place. They obsess over prompts, when the real problem is structural: agents are dropped into repositories that were never designed for them. The solution was to make the repository itself agent-native through a standardized instruction layer like AGENTS.md.

But even after you fix the environment, something still breaks.

The agent starts strong. It understands the problem, follows instructions, seems super intelligent

Then, somewhere along the way, things begin to drift. The code still compiles, but the logic gets inconsistent. Small mistakes creep in. Constraints are ignored. Assumptions mutate.

Nothing fails loudly. Everything just gets slightly worse.

This is the second failure mode of AI systems: context rot.

Context Rot Is Not a Bug — It’s a Property

There is a persistent assumption in the industry that more context leads to better performance. If a model can handle large context windows, then giving it more information should improve accuracy.

In practice, the opposite is often true.

Recent research from Chroma shows that LLM performance degrades as input length increases, even when the model is operating well within its maximum context window. Similar observations are echoed across independent analyses, including this breakdown of why models deteriorate in longer sessions and practical explorations of how context mismanagement impacts production systems.

This is not an edge case. It is a structural limitation.

Models do not “understand” context in a hierarchical way. They distribute attention across tokens. As context grows, signal competes with noise. Important instructions lose weight. Irrelevant details gain influence. Conflicts accumulate.

What looks like a reasoning failure is often just context degradation.

Why Long Sessions Break Down

If you’ve worked with AI coding agents for more than a few hours, you’ve already seen this pattern.

A session starts with clear instructions and aligned reasoning. Over time, it fills with partial implementations, outdated assumptions, repeated instructions, and exploratory dead-ends. The model doesn’t forget earlier information, it simply cannot prioritize it effectively anymore.

Detailed guides on context management highlight this exact failure mode: as sessions grow, models become increasingly sensitive to irrelevant or redundant tokens, which degrade output quality. Platform-level documentation also reinforces the same principle - effective systems explicitly control how context is introduced, retained, and pruned.

In practice, this shows up as inconsistency. But underneath, it’s the predictable outcome of unmanaged context growth.

The Link Between Context Rot and Hallucination

This is where teams often misdiagnose the issue.

When agents hallucinate, the instinct is to blame the model. But hallucination is often downstream of context rot.

OpenAI’s work on hallucinations explains that models are optimized to produce plausible outputs even under uncertainty. When context degrades, uncertainty increases. The model fills gaps with statistically likely answers.

So the failure chain looks like this:

Context degradation → ambiguity → confident guessing → hallucination

In other words, hallucination is not always a knowledge problem.
It is often a context management problem.

Sessions Are Not Conversations

Most developers interact with AI through chat, so they treat sessions like conversations.

That mental model breaks at scale.

A long-running AI session is not a conversation. It is a stateful system.

And like any stateful system, it degrades without control.

Letting context accumulate indefinitely is equivalent to running a system without memory management. Eventually, performance collapses—not because the system is incapable, but because it is overloaded.

The Plan → Execute → Reset Discipline

Once you accept that context degrades, the solution becomes straightforward: you don’t try to out-prompt the problem. You control how context evolves.

Across production teams, a consistent pattern emerges:

Plan → Execute → Reset

This is not a trick. It is operational discipline.

Planning before execution

The most common mistake is asking the agent to write code immediately. This forces premature decisions and locks the model into an approach before it has fully understood the problem.

Instead, enforce a planning phase.

Have the model break down the task, identify dependencies, and surface uncertainties before implementation. This aligns closely with best practices in production-grade prompt engineering, where structured reasoning is prioritized over immediate generation.

Planning reduces unnecessary context growth and prevents incorrect assumptions from propagating.

Stepwise execution

Once the plan is validated, execution should be incremental.

Large, monolithic prompts create large, monolithic contexts—and those degrade fastest.

Stepwise execution keeps the working context focused. Each step introduces only the information required for that step. Errors are caught early, before they spread across the system.

This is not about slowing down development. It is about maintaining signal integrity.

Resetting the session

Even with disciplined execution, context will eventually degrade.

The only reliable solution is to reset.

This may feel inefficient, but in practice, it is one of the highest-leverage actions you can take. A fresh session restores clarity, removes noise, and re-establishes correct prioritization of instructions.

Modern context management approaches consistently emphasize this: keep context bounded, and reintroduce only what is necessary for the task at hand.

Meta-Prompting: Forcing the Model to Think First

One of the most effective techniques for preventing context rot is meta-prompting.

Instead of telling the model what to do, you tell it how to approach the task.

You explicitly require it to:

identify assumptions
highlight uncertainties
ask clarifying questions

This interrupts the model’s default behavior of immediate generation.

Why does this work?

Because hallucinations are often driven by premature certainty. Meta-prompting introduces friction at exactly the right point—before incorrect assumptions become embedded in the context.

Checkpoints: Turning Drift into Signal

Context rot is dangerous because it is gradual and often invisible.

Checkpoints make it observable.

At key moments, you force the model to validate its output against:

the original task
repository constraints (AGENTS.md)
architectural expectations

This transforms hidden drift into explicit feedback.

Instead of discovering problems at the end, you correct them continuously.

The Connection to Part 1

Part 1 of the series solved the problem of what the agent sees.

Part 2 addresses what happens over time.

AGENTS.md provides structure.
Session discipline preserves that structure.

Without AGENTS.md, the agent guesses.
Without discipline, the agent drifts.

You need both to achieve reliable outcomes.

Why This Matters Now

As teams move from experimentation to production, sessions become longer and more complex. Agents interact with more systems, touch more code, and accumulate more context.

This is where most failures emerge.

Not because the model is incapable, but because the workflow is uncontrolled.

Context rot is the primary bottleneck in real-world AI engineering today.

Before You Scale, You Stabilize

In Part 3, we turn to a different problem.

So far, we have focused on a single agent operating within a controlled session. That constraint makes it possible to reason about context, to reset it, and to keep it aligned with the task.

But most real systems do not stay within that boundary.

As soon as you introduce multiple agents, external tools, or retrieval systems, the problem changes. Context is no longer contained in a single session. It becomes distributed across components that do not share the same state or assumptions.

At that point, failures become harder to trace. Drift is no longer local. It propagates.

This is where orchestration becomes necessary, but also where it becomes risky.

Part 3 explores how to build these systems in a way that preserves the guarantees established here. We will look at how to introduce MCPs, subagents, and external integrations without losing control over context, consistency, or behavior.

Technical

Operationalizing Production Data Testing with Harness Database DevOps

Automate production data testing with Harness DB DevOps. Validate schema changes, rollback safety, and reduce deployment risk in CI/CD pipelines.

Animesh Pathak

April 1, 2026

Time to read

Testing database changes against production-like data removes risk from your delivery process but to be effective, it must be orchestrated, governed, and automated. Manual scripts and ad-hoc checks lack the repeatability and auditability required for modern delivery practices.

Harness Database DevOps provides a framework to embed production data testing into your CI/CD pipelines, enabling you to manage database schema changes with the same rigor as application code. Harness DB DevOps is designed to bridge development, operations, and database teams by bringing visibility, governance, and standardized execution to database changes.

Instead of treating testing with production data as an afterthought, you can define it as a pipeline stage that executes reliably across environments.

A Pipeline-Driven Reference Workflow

To incorporate production data testing into your delivery process, you define a Harness Database DevOps pipeline with structured, repeatable steps. The result is a governed testing model that captures evidence of correctness before any change ever reaches production.

Stage 1: Environment Provisioning and Data Preparation

In Harness Database DevOps, you begin by configuring the necessary database instances and schemas:

DB Schemas are defined in Git, using Liquibase or Flyway changelogs or script-based SQL files under version control.
DB Instances connect to your target environments with credentials and Delegate access configured.

For production data testing, you provision two isolated instances seeded with a snapshot of production data (secured and masked as needed). These instances are not customer-facing; they serve as ephemeral test targets.

This structure sets up identical baselines for controlled experimentation.

Stage 2: Schema Application Within a Harness Pipeline

Harness Database DevOps lets you define a deployment pipeline that incorporates database and application changes in the same workflow:

Pipelines unify database deployments with application delivery.
You add stages such as “Apply Schema Changes” that reference your DB Schema and DB Instance.

Using Liquibase or Flyway via Harness, the pipeline applies schema changes to Instance A while Instance B remains the baseline.

This step executes the migration in a real, production-scale context, capturing performance, constraint behaviors, and other runtime characteristics.

Stage 3: Automated Rollback and Undo Migration Testing

A powerful capability of Harness Database DevOps is automated rollback testing within the pipeline:

The pipeline can execute undo migrations to revert schema changes.
Pipelines track execution results and rollback outcomes, enabling teams to validate that undo logic works reliably.

Testing rollback paths removes the assumption that reversal will work in production, a key risk often untested in traditional workflows.

Stage 4: Comparison Against Baseline and Validation

After rollback, you compare Instance A (post-rollback) with Instance B (untouched):

At this point, they should be identical in schema and data state.
Tools designed for database comparisons (e.g., DiffKit) can be integrated to perform row-level and schema-level verification, highlighting hidden drifts or silent mutations.

If disparities are detected, the pipeline can fail early, prompting review and remediation before production deployment.

This approach builds evidence rather than assumptions about the quality and safety of database changes.

How This Aligns with Harness Capabilities?

The updated workflow aligns with the documented capabilities of Harness Database DevOps:

Orchestration of database changes as part of CI/CD pipelines with visibility across environments.
Governance and approvals, so schema changes are reviewed and compliant.
Integrated rollback support for automated undo migrations.
Unified interface and audit trails to track which changes ran where and when.

Importantly, the workflow does not assume native data cloning features within Harness itself. Instead, it positions data-centric operations (cloning and validation) as composable steps in a broader automation pipeline.

Strategic Outcomes for Engineering Teams

Embedding production data testing inside Harness Database DevOps pipelines delivers measurable outcomes:

Reduced risk of production incidents by catching issues early.
Repeatable, auditable delivery practices, aligning database changes with application code flows.
Clear rollback evidence, not just theoretical promise.
Improved collaboration between developers and DBAs through pipeline transparency.

This integrated, pipeline-oriented approach elevates database change management into a disciplined engineering practice rather than a set of isolated tasks.

Conclusion

Database changes do not fail because teams lack skill or intent. They fail because uncertainty is tolerated too late in the delivery cycle when production data, scale, and history finally collide with untested assumptions.

Testing with production data, when executed responsibly, shifts database delivery from hope-based validation to evidence-based confidence. It allows teams to validate not just that a migration applies, but that it performs, rolls back cleanly, and leaves no hidden drift behind. That distinction is the difference between routine releases and high-severity incidents.

By operationalizing this workflow through Harness Database DevOps, organizations gain a governed, repeatable way to:

Treat database changes as first-class citizens in CI/CD
Validate forward and rollback paths against real data
Produce auditable proof of correctness before production
Scale database delivery without scaling risk

This is not about adding more processes. It is about removing uncertainty from the most irreversible layer of your system.

Explore a Harness Database DevOps to see how production-grade database testing, rollback validation, and governed pipelines can fit seamlessly into your existing workflows The fastest teams don’t just deploy quickly, they deploy with confidence.

Technical

The Dangerous Myth: “We Have SCA, So We’re Covered”

SCA alone isn’t enough. Secure your supply chain by governing pipelines, artifacts, containers, and AI across build, promotion, and runtime stages.

Bri Strozewski

April 1, 2026

Time to read

SCA provides visibility into open source risk but leaves artifacts, pipelines, containers, and AI components exposed.
CI/CD pipelines are privileged infrastructure and must be treated as zero-trust environments.
Build systems are a critical trust boundary; artifact attestation and registry gating are essential.
Container images, third-party integrations, and AI models are now active supply chain attack vectors.
True supply chain security requires control at ingest, build, promotion, and runtime — not just scanning.

Most organizations begin their software supply chain journey the same way: they implement Software Composition Analysis (SCA) to manage open source risk. They scan for vulnerabilities, generate SBOMs, and remediate CVEs. For many teams, that feels like progress—and it is.

But it is not enough.

As discussed in the webinar conversation with Information Security Media Group, open-source visibility is necessary, but it is not sufficient. Modern applications are no longer just collections of third-party libraries. They are built, packaged, signed, stored, promoted, deployed, and increasingly augmented by AI systems. Each stage introduces new dependencies and new trust boundaries.

Events like Log4j made open source risk impossible to ignore. However, the evolution of the threat landscape has demonstrated that attackers are no longer limited to exploiting known vulnerabilities in libraries. They are targeting the mechanics of delivery itself—ingestion, build pipelines, artifact storage, and CI/CD automation. Organizations that stop at SCA are securing one layer of a much broader system.

Where Modern Supply Chains Actually Get Compromised

Artifact Integrity and Registry Blind Spots

Artifacts are the final outputs of the build process—container images, binaries, scripts, Helm charts, JAR files. They are what actually run in production. Yet many organizations treat artifact management as operational plumbing rather than a security control point.

The webinar highlighted how focusing exclusively on source code can obscure the reality that artifacts may be tampered with after build, altered during promotion, or stored in misconfigured registries. Visibility into open source dependencies does not automatically guarantee artifact integrity. An attacker who compromises a registry or intercepts promotion workflows can distribute malicious artifacts at scale.

The key risk lies in assuming that once an artifact is built, it is trustworthy. Without signing, provenance tracking, and gating at the registry level, artifacts become one of the most exploitable surfaces in the supply chain.

CI/CD Pipelines as Privileged Infrastructure

CI/CD systems hold credentials, secrets, deployment paths, and signing keys. They connect development directly to production. As one of the speakers noted during the discussion, pipelines should be treated as privileged infrastructure and assumed to be potential targets of compromise.

A compromised runner can publish malicious artifacts, exfiltrate secrets, or promote unauthorized builds. This is not theoretical. Attacks involving poisoned GitHub Actions and manipulated build systems demonstrate how easily the pipeline itself can become the distribution mechanism.

Security must therefore extend beyond scanning artifacts to enforcing strict governance within pipelines. This includes least privilege access, ephemeral credentials, audit trails, and Policy as Code enforcement to ensure required security checks cannot be bypassed.

Containers and Upstream Image Poisoning

Container ecosystems introduce additional risk vectors. Malicious images uploaded to public registries, typosquatting packages, and compromised upstream components can all infiltrate environments through seemingly legitimate pulls.

Organizations that implicitly trust external registries transfer vendor risk into their own infrastructure. Without upstream proxy controls, cool-off periods, or quarantine mechanisms, container ingestion becomes another blind spot.

The supply chain does not stop at internal code repositories. It extends to every external source that feeds into the build.

Vendor and Third-Party Integration Risk

Modern delivery pipelines integrate numerous third-party services. Vendors often have privileged access to environments or automated integrations into CI/CD workflows. If a vendor is compromised, that risk propagates downstream.

The webinar discussion emphasized that the supply chain must be viewed as a “trust fabric.” Pipelines, registries, and vendors are all part of that fabric. A weakness in any one node can cascade across the system.

Build Systems Are the New Trust Boundary

Build systems represent one of the most underestimated attack surfaces in modern software delivery. A source tree may pass review and scanning, yet small modifications in the build process can fundamentally alter the resulting artifact.

Examples discussed during the session included pre-install hooks, registry overrides, runtime installers, or seemingly minor shell script changes that introduce malicious behavior before artifacts are signed or scanned. These changes can bypass traditional SCA tools because the underlying source code appears clean.

This is why build integrity must be verifiable. Provenance should be recorded and tied to specific systems and identities. Build steps should be signed and attested. Promotion gates should require verification of those attestations before artifacts move forward.

Trust must be anchored in the build output, not assumed from the source input.

Why Pipelines Must Be Treated as Untrusted

CI/CD pipelines are often viewed as automation tools, but they are in fact highly privileged systems that bridge development and production. They hold secrets, manage deployment logic, and often operate with broad permissions across infrastructure.

The webinar discussion stressed that pipelines must be treated as untrusted environments by default. This does not imply mistrust of developers, but rather recognition that any high-privilege system is an attractive target.

Policy-as-code frameworks, strict RBAC, auditability, and enforcement of mandatory security checks ensure that controls cannot be disabled under pressure to ship. Developers may unintentionally bypass safeguards when under deadlines. Governance mechanisms must therefore be systemic, not optional.

In complex environments where multiple tools—GitHub Actions, Jenkins, Docker, Kubernetes—are integrated together, misconfiguration becomes another source of risk. Each tool has its own security model. Without centralized governance, complexity compounds vulnerability.

AI Is Expanding the Supply Chain Attack Surface

As if artifacts, pipelines, and containers were not enough, AI-native applications are adding an entirely new dimension to supply chain security.

Modern applications increasingly rely on Large Language Models, prompt libraries, embeddings, model weights, and training datasets. These components influence runtime behavior in ways that traditional code does not. Yet they are rarely tracked or governed with the same rigor as open-source dependencies.

The concept of an “AI Bill of Materials” is emerging, but no standardized framework currently exists. Organizations are integrating AI features faster than governance standards can keep pace.

The risks differ from traditional CVEs. Poisoned training data can subtly manipulate model behavior. Backdoored model weights can introduce hidden functionality. Prompt injection attacks can trick systems into exposing sensitive information. Shadow AI systems may be deployed without formal oversight.

Unlike deterministic software, AI systems produce probabilistic outputs. Static security testing does not fully address this unpredictability. Security teams must now consider model provenance, data lineage, vendor trust, and runtime behavior monitoring as part of the supply chain equation.

Even the build-versus-buy decision for LLMs becomes a supply chain governance choice. Building offers control but introduces operational burden and long-term responsibility. Buying accelerates deployment but increases trust dependency on external vendors. In both cases, AI components extend the trust fabric and must be governed accordingly.

A Practical Framework for End-to-End Supply Chain Security

Moving beyond SCA requires structured controls across the full lifecycle of delivery.

Ingest-Time Controls ensure that risky packages and images are prevented from entering developer workflows in the first place through dependency firewalls, upstream proxy governance, and vendor controls.

Build-Time Integrity requires signed environments, provenance attestations, and enforcement of SLSA-style compliance so that artifacts can be cryptographically tied to verified build processes.

Promotion-Time Governance introduces artifact registry gating, quarantine workflows, and policy enforcement to prevent unauthorized or tampered artifacts from advancing to production.

Runtime Verification ensures continuous monitoring of deployment health, secret usage, and, increasingly, AI behavior to detect anomalous activity after release.

This layered approach transforms supply chain security from a reactive scanning function into an operational control system embedded directly into software delivery workflows.

From Visibility to Control

Software supply chain security has evolved.

It is no longer an open-source vulnerability problem alone. It is a trust management challenge spanning artifacts, pipelines, containers, vendors, and AI components.

Organizations that succeed will not stop at generating reports. They will enforce policy at every stage. They will treat CI/CD as privileged infrastructure. They will require attestations before promotion. They will govern ingestion and monitor runtime behavior. They will extend security controls into AI-native systems.

Supply chain security must move beyond visibility. It must deliver enforceable control across the entire software delivery lifecycle. Software supply chain security isn’t about scanning more. It’s about governing every stage of software delivery from code to artifact to pipeline to production to AI.

Ready to see how Harness embeds supply chain security directly into CI/CD, artifact governance, and AI-powered verification?

Explore Harness Software Supply Chain Security solutions and secure your delivery pipeline end-to-end.

FAQs

Is SCA enough for software supply chain security?

No. SCA provides visibility into open-source vulnerabilities but does not protect CI/CD pipelines, artifact integrity, container ecosystems, or AI components.

Why are CI/CD pipelines considered high-risk?

Pipelines hold credentials, signing keys, and deployment paths. A compromised runner can inject malicious artifacts or exfiltrate secrets.

What is artifact governance?

Artifact governance includes registry gating, quarantine workflows, attestation verification, and policy enforcement before artifacts are promoted or deployed.

What is an AI Bill of Materials (AI-BOM)?

An AI-BOM would catalog AI components such as models, prompts, embeddings, and training data. Standards are still emerging.

How do supply chain attacks bypass SCA?

They exploit ingestion workflows, build steps, compromised pipelines, or malicious container images — rather than known CVEs.

Should organizations build or buy LLMs?

Build offers control but high cost and operational burden. Buy offers speed and vendor expertise but introduces trust and governance risks.

Engineering Blog

Your Repo Is a Knowledge Graph. You Just Don't Query It Yet.

SCM is evolving into Source Context Management, enabling AI agents with rich, precomputed context to improve accuracy, speed, and reliability in software development.

Ompragash Viswanathan

April 1, 2026

Time to read

Why Source Code Management must become Source Context Management in the age of AI agents

The Premise

For decades, SCM has meant one thing: Source Code Management. Git commits, branches, pull requests, and version history. The plumbing of software delivery. But as AI agents show up in every phase of the software development lifecycle, from writing a spec to shipping code to reviewing a PR, the acronym is quietly undergoing its most important transformation yet.

SCM is becoming Source Context Management.

And this isn't a rebrand. It's a rethinking of what a source repository is, what it stores, and what it serves, not just to developers, but to the agents working alongside them.

The Context Crisis in Agentic SDLC

AI agents in software development are powerful but contextually blind by default. Ask a coding agent to implement a feature and it will reach out and read files, one by one, directory by directory, until it has assembled enough context to act. Ask a code review agent to assess a PR and it will crawl through the codebase to understand what changed and why it matters.

Anthropic's 2026 Agentic Coding Trends Report documents this shift in detail: the SDLC is changing dramatically as single agents evolve into coordinated multi-agent teams operating across planning, coding, review, and deployment. The report projects the AI agents market to grow from $7.84 billion in 2025 to $52.62 billion by 2030. But as agents multiply across the lifecycle, so does their hunger for codebase context, and so does the cost of getting that context wrong.

This approach has two brutal failure modes:

Context window bloat. Feeding raw source files to an LLM is expensive, slow, and lossy. A 300,000-line codebase doesn't fit in any context window. The agent is forced to guess what's relevant, and it often guesses wrong.
Semantic blindness. Reading files doesn't tell an agent why code is structured the way it is, what modules depend on what, which functions are high-risk, or what the design philosophy behind a component is. Text is not meaning.

The result? Agents that hallucinate implementations because they missed a key abstraction three directories away. Code reviewers that flag style issues but miss architectural regressions. PRD generators that know the syntax of your codebase but not its soul.

The bottleneck is not the model. It is the absence of a pre-computed, semantically rich, always-available representation of the entire codebase: a context engine.

A Tale of Two Agents

Consider a simple task: "Add rate limiting to the /checkout endpoint."

Without a context engine, a coding agent opens checkout.go, reads the handler function, and writes a token-bucket rate limiter inline at the top of the handler. The code compiles. The tests pass. The PR looks clean.

The agent missed three things:

The service already uses a middleware-based rate limiting pattern in middleware/ratelimit.go for every other endpoint. The agent created a second, inconsistent approach.
A shared RateLimitConfig interface exists that all rate limiters must implement for centralized configuration management. The agent's inline implementation ignores it.
Every rate-limit event flows through a centralized metrics.Emit() call for observability dashboards. The agent's version remains invisible to ops.

The code works. The team that maintains it finds it wrong in every way that matters. A senior engineer catches these issues in review, requests changes, and the cycle restarts. Multiply this by every agent-generated PR across every team, every day.

With a context engine, the same agent queries before writing code: "How is rate limiting implemented in this service?" The context engine returns:

The existing middleware pattern in middleware/ratelimit.go
The RateLimitConfig interface it must implement
The metrics.Emit() integration point for observability
The test conventions in middleware/ratelimit_test.go

The agent writes a new rate limiter that follows the established pattern, implements the shared interface, emits metrics through the standard pipeline, and includes tests that match the existing style. The PR wins approval on the first pass.

The difference is context quality, not model quality.

Beyond LSP: From Interactive Intelligence to Agentic Intelligence

The Language Server Protocol (LSP) transformed developer tooling in the past decade. By standardizing the interface between editors and language-aware backends, LSP gave every IDE, from VS Code to Neovim, access to autocomplete, go-to-definition, hover documentation, and real-time diagnostics. LSP was designed to serve a specific consumer: a human developer, working interactively, in a single file at a time. That design made the right trade-offs for its era:

Interactive response optimization. Servers pre-compute and cache indices for low-latency, cursor-anchored queries rather than producing complete semantic snapshots of entire repositories on demand
Position orientation. Most queries anchor to a file and cursor position, perfect for an editor but limiting for full-repo semantic traversal
Session binding. Requires an active language server process, tightly coupled to an open editor session
Single-client design. The protocol assumes one client per server instance, not built for concurrent multi-agent access

For interactive development, these are strengths. LSP excels at what it was built to do.

Agents are a different class of consumer. They don't sit in a file waiting for cursor events. They operate across entire repositories, across SDLC phases, often in parallel. They need the full semantic picture before they start, not incrementally as they navigate.

Agents need not a replacement for LSP, but a complement: something pre-built, always available, queryable at repo scale, and semantically complete, ready before anyone opens a file.

Enter LST: The Foundation of Source Context Management

Lossless Semantic Trees (LST), pioneered by the OpenRewrite project (born at Netflix, commercialized by Moderne), take a different approach to code representation.

Unlike the traditional Abstract Syntax Tree (AST), an LST:

Preserves formatting. Whitespace, comments, style decisions are retained, enabling round-trip code transformation without destructive rewrites
Is fully type-attributed. Every node in the tree knows the full type of every symbol, including fields defined in external binary dependencies
Is pre-computed and cacheable. LSTs are generated once, stored, and queried repeatedly without needing a live language server
Scales to entire repositories. Moderne's platform has demonstrated querying and transforming hundreds of millions of lines of code in seconds using pre-stored LSTs

This is the first layer of a Source Context Management system. Not raw files. Not a running language server. A pre-indexed semantic tree of the entire codebase, queryable by agents at any time.

The Three-Layer Architecture of a Context Engine

A proper Source Context Management system is not a single component. It is a three-layer stack that turns a repository from a file store into something agents can actually reason over.

Layer 1: Semantic Indexing (LST + Embeddings)

Every file in the repository is parsed into an LST and simultaneously embedded into a vector representation. This creates two complementary indices:

Structural index (LST): knows types, dependencies, call hierarchies, inheritance chains
Semantic index (vectors): knows meaning, intent, similar patterns, conceptual proximity

Layer 2: Code Graph

The LST and semantic indices are projected into a code knowledge graph, a property graph where nodes are functions, classes, modules, interfaces, and comments, and edges are relationships: calls, imports, inherits, implements, modifies, tests.

This graph enables queries like:

"What is the blast radius if I change this interface?"
"Which modules have never been touched by the team that owns this service?"
"What are all the callers of this deprecated function across microservices?"
"Which code paths are covered by zero tests?"

Layer 3: Agentic Integration (MCP / API)

The context engine exposes itself through a Model Context Protocol (MCP) server or REST API, so any agent (whether a coding agent, a review agent, a risk assessment agent, or a documentation agent) can query the context engine directly, retrieving precisely the subgraph or semantic chunk it needs, without ever touching the raw file system.

The key insight: agents never read files. They query the context engine.

One Context Engine, Entire SDLC

A single context engine can serve every phase of the software development lifecycle.

Product Requirements (PRD Generation)

A PRD agent queries the context engine to understand existing capabilities, technical constraints, and module boundaries before generating a requirements document. It produces specs grounded in what the system actually is, not what someone thinks it is.

Technical Specification

A spec agent traverses the code graph to identify affected components, surface similar prior implementations, flag integration points, and propose an architecture, all without reading a single file directly.

Implementation (Coding)

A coding agent retrieves the precise subgraph surrounding the feature area: the types it needs to implement, the interfaces it must satisfy, the patterns used in adjacent modules, the test conventions for this package. It writes code that fits the codebase, not just code that compiles.

Pull Request & Code Review

A review agent queries the context engine to understand the semantic diff, not just what lines changed, but what that change means for the rest of the system. It can immediately surface:

Functions that are now unreachable
Breaking changes to downstream consumers
Regressions in design patterns
Missing test coverage for the changed blast radius

Risk Assessment

A risk agent scores every PR against the code graph, identifying high-centrality nodes (code that many things depend on), historically buggy modules, and changes that cross team ownership boundaries. No DORA metrics spreadsheet required.

Documentation & Design Principles

A documentation agent can traverse the code graph to generate living documentation (architecture diagrams, module dependency maps, API contracts) that updates automatically as the codebase evolves. Design principles can be encoded as graph constraints and validated on every merge.

Incident Response

When a production incident occurs, an on-call agent queries the context engine with the failing component and gets an immediate blast-radius map, the last 10 changes to that subgraph, the owners, and the test coverage status. Time-to-understanding drops from hours to seconds.

The Business Imperative

The business case is simple:

Developer productivity. Agents with accurate context write correct code on the first pass. Fewer review cycles, fewer reverted commits, fewer rollbacks.
Delivery velocity. Pre-computed context means agents don't spend half their time reading the codebase. Tasks that take minutes of agent compute today can take seconds.
Risk reduction. A code graph makes the blast radius of every change visible before it merges. Risk moves left, from production incidents to pre-merge awareness.
Institutional memory. The context engine captures why code is structured the way it is, not just what it does. New engineers (and new agents) onboard against the graph, not against tribal knowledge.

The Open Source Ecosystem Is Already Here

This is not a theoretical architecture. Tools exist today:

OpenRewrite / Moderne. LST generation and large-scale codebase transformation
tree-sitter. Universal parser for building ASTs across 150+ languages
CodeRAG. Graph-based code analysis for AI-assisted development
ArangoDB / FalkorDB / Neo4j / Memgraph. Graph databases well-suited for code relationship storage
Chroma / Qdrant / Milvus. Vector databases for semantic code embeddings
MCP (Model Context Protocol). Anthropic's open protocol for agent-to-tool communication
Context-aware code review engines. Platforms that leverage semantic code understanding to power AI-assisted review beyond surface-level linting

The missing piece is not any individual component. It is the platform that assembles them into a unified, repo-attached context engine that every agent in the SDLC can query through a single interface.

The Challenges to Solve

Source Context Management faces real engineering challenges:

Security and access control. A context engine is a pre-analyzed, queryable understanding of the codebase: dependency chains, blast-radius maps, test coverage gaps, ownership boundaries. In the wrong hands, this becomes a penetration testing roadmap. Agents querying the context engine must respect the same repo-level permissions that developers have, enforced at the graph query level, not just the API boundary. Context leakage across team or tenant boundaries is the single highest-severity threat vector this architecture introduces. Any serious deployment must treat threat modeling as a first-class architectural concern. Anthropic's 2026 Agentic Coding Trends Report makes the same call, listing "security-first architecture" as one of eight defining trends for agentic coding.
Polyglot repos. Most enterprise codebases span multiple languages. The context engine must support unified graph construction across Java, Python, TypeScript, Go, and more simultaneously.
Index freshness. The context engine must update incrementally on every commit, much like Git's own index, which uses content-addressable hashing and stat caching to detect exactly what changed without re-reading every file. A context engine that rebuilds from scratch on every push will not scale; one that recomputes only the affected subgraph on each commit will. A stale graph is worse than no graph, because it gives agents false confidence.
Graph scale. A 10-million-line monorepo produces a graph with hundreds of millions of edges. Query performance at this scale requires dedicated graph infrastructure.
Evaluation. How do you measure whether an agent's output improved because the context engine was accurate? Building evals for context quality is an unsolved problem.

The Reframe: What Is a Repository?

This is the shift:

A repository is not a collection of files. A repository is a knowledge graph with a version history attached.

Git's job is to version that knowledge. The context engine's job is to make it queryable. The agent's job is to act on it.

Follow this model and the consequences are concrete. Every CI/CD pipeline should include a context engine update step, as natural as running tests. Every developer platform should expose a context engine API alongside its code hosting API. Every AI coding tool should be evaluated not just on model quality but on context engine quality.

Source code repositories that don't invest in their context layer will produce agents that are fast but wrong. Repositories with rich, well-maintained context engines will produce agents that feel like senior engineers, because they have the same depth of understanding of the codebase that a senior engineer carries in their head.

Conclusion: The Next Infrastructure Primitive

The LSP gave us IDE intelligence. Git gave us version control. Docker gave us portable environments. Kubernetes gave us cluster orchestration. Each of these was an infrastructure primitive that unlocked a new generation of developer tooling.

The Source Context Engine is the next infrastructure primitive.

It is the prerequisite for every agentic SDLC capability worth building. And like every infrastructure primitive before it, the teams and platforms that build it first will be hard to catch.

SCM is no longer just about managing source code. It's about managing the context that makes the source code understandable.

Technical

Terraform Vendor Lock-In: How to Escape It

Terraform vendor lock-in is real. Learn how OpenTofu and Harness IaCM help you escape it and manage multi-IaC environments. Explore now.

Richard Black

March 31, 2026

Time to read

Did ecTerraform vendor lock-in just become your biggest operational risk without you noticing? When HashiCorp changed Terraform's license from MPL to BSL in August 2023, legal terms were not the only alteration. They fundamentally shifted the operational landscape for thousands of platform teams who built their infrastructure automation around what they believed was an open, community-driven tool. If your organization runs Terraform at scale, you're now facing a strategic decision that wasn't on your roadmap six months ago.

The uncomfortable truth is that most teams didn't architect for IaC portability. Why would they? Terraform was open source. It was the standard. And now, many organizations find themselves in a position they swore they'd never be in again after the Kubernetes wars: locked into a single vendor's roadmap, pricing model, and strategic priorities.

This isn't theoretical; it’s the very serious reality platform engineers are dealing with right now!

Why Terraform Lock-In Became Real Overnight

Terraform lock-in wasn't always a concern. For years, Terraform represented the opposite of vendor lock-in. It was open source, cloud-agnostic, and community-driven. Teams built entire operational models around it. They trained engineers, standardized on HCL, built module libraries, and integrated Terraform deeply into CI/CD pipelines. You’ve got to hand it to them; these aspects were very desirable.

Then HashiCorp moved to the Business Source License. Suddenly, the "open" in "open source" came with conditions. The BSL restricts certain commercial uses, and while many organizations technically fall outside those restrictions, the change introduced uncertainty.

Could HashiCorp tighten the license further?
Would future versions include features only available under commercial terms?
What happens when your infrastructure automation depends on a tool whose strategic direction you no longer control?

The deeper problem is architectural. Most teams didn't design for IaC engine portability because they didn't need to. Terraform state files, provider interfaces, and workflow patterns became embedded assumptions. Module libraries assumed Terraform syntax. Pipelines called `terraform plan` and `terraform apply` directly. When every workflow is tightly coupled to a single tool's CLI and API, switching becomes expensive.

This is classic vendor lock-in, even if it happened gradually and without malice.

The Hidden Costs of Staying Locked In

The immediate cost of Terraform lock-in isn't the license itself, but rather related to what you can't do when you're locked in.

You can't experiment with alternative IaC engines without rewriting modules.
You can't adopt tools that might better suit specific use cases.
You can't negotiate from a position of strength because your entire infrastructure automation stack depends on one vendor's roadmap.

If HashiCorp decides to sunset features, deprecate APIs, or introduce breaking changes, you either adapt or do without; stuck on an outdated version with mounting technical debt.

The operational risk compounds over time. When you're locked into a single IaC tool, you're also locked into its limitations. If drift detection isn't native, you build workarounds. If policy enforcement is bolted on, you maintain custom integrations. If the state backend causes performance issues at scale, you optimize around the bottleneck rather than solving the root problem.

And then there's the talent risk. If your team only knows Terraform, and the industry shifts toward other IaC paradigms, you're either retraining everyone or competing for a shrinking talent pool. Monocultures are fragile.

How to Escape Terraform Lock-In Without Rewriting Everything

The good news is that escaping Terraform lock-in doesn't require a full rewrite. It requires a deliberate strategy to introduce portability into your IaC architecture.

Start with OpenTofu as Your Baseline

OpenTofu emerged as the open-source fork of Terraform immediately after the license change. It's MPL-licensed, community-governed through the Linux Foundation, and API-compatible with Terraform 1.5.x. For most teams, OpenTofu migration is the lowest-friction path to regaining control over your IaC engine.

Migrating to OpenTofu doesn't mean abandoning your existing Terraform workflows. Because OpenTofu maintains compatibility with Terraform's core primitives, you can run OpenTofu side-by-side with Terraform during a transition. This lets you validate behavior, test edge cases, and build confidence before committing fully.

The strategic advantage of OpenTofu is not just licensing, optionality. Once you're no longer tied to HashiCorp's roadmap, you can evaluate IaC engines based on technical merit rather than sunk cost.

Decouple Your Workflows from Engine-Specific Assumptions

The harder part of escaping IaC vendor lock-in is decoupling your operational workflows from Terraform-specific patterns. This means abstracting your pipelines so they don't hardcode `terraform plan` and `terraform apply`. It means designing module interfaces that could theoretically support multiple engines. It means treating the IaC engine as an implementation detail rather than the foundation of your architecture.

This is where infrastructure as code portability becomes a design principle. If your pipelines call a generic "plan" and "apply" interface, switching engines becomes a simple configuration change, not a migration project.

Adopt Multi-IaC Tool Management from the Start

The reality is that most large organizations will eventually run multiple IaC tools. Some teams will use OpenTofu. Others will stick with Terraform for compatibility with existing state. New projects might adopt Terragrunt for DRY configurations or Pulumi for type-safe infrastructure definitions.

Fighting this diversity creates friction. Embracing it requires tooling that supports multi-IaC environments without forcing everyone into a lowest-common-denominator workflow. You need a platform that treats OpenTofu, Terraform, and other engines as first-class citizens, not as competing standards.

How Harness IaCM Enables Vendor-Neutral Infrastructure Management

Harness Infrastructure as Code Management was built to solve the multi-IaC problem that most teams are only now realizing they have. It doesn't force you to pick a single engine. It doesn't assume Terraform is the default. It treats OpenTofu and Terraform as equally supported engines, with workflows that abstract away engine-specific details while preserving the flexibility to use either.

This matters because escaping Terraform lock-in isn't just about switching tools. It's about building infrastructure automation that doesn't collapse the next time a vendor changes direction.

Harness IaCM supports OpenTofu and Terraform natively, which means you can run both engines in the same platform without maintaining separate toolchains. You get unified drift detection, policy enforcement, and workspace management across engines. If you're migrating from Terraform to OpenTofu, you can run both during the transition and compare results side-by-side.

The platform also supports Terragrunt, which means teams that have invested in DRY Terraform configurations don't have to throw away that work to gain vendor neutrality. You can keep your existing module structure while gaining the operational benefits of a managed IaC platform.

Beyond engine support, Harness IaCM addresses the systemic problems that make IaC vendor lock-in so painful. The built-in Module and Provider Registry means you're not dependent on third-party registries that could introduce their own lock-in. Variable Sets and Workspace Templates let you enforce consistency without hardcoding engine-specific logic into every pipeline. Default plan and apply pipelines abstract away the CLI layer, so switching engines doesn't require rewriting every workflow.

Drift detection runs continuously, which means you catch configuration drift before it becomes an incident. Policy enforcement happens at plan time, which means violations are blocked before they reach production. These aren't afterthoughts or plugins. They're native platform capabilities that work the same way regardless of which IaC engine you're using.

And because Harness IaCM is part of the broader Harness Platform, you can integrate IaC workflows with CI/CD, feature flags, and policy governance without duct-taping together disparate tools. This is the architectural model that makes multi-IaC tool management practical at scale.

Explore the Harness IaCM product or dive into the technical details in the IaCM docs.

The Path Forward: Portability as a Design Principle

Escaping Terraform lock-in is not about abandoning Terraform everywhere tomorrow. It's about regaining strategic control over your infrastructure automation. It's about designing for portability so that future licensing changes, roadmap shifts, or technical limitations don't force another painful migration.

The teams that will navigate this transition successfully are the ones that treat IaC engines as interchangeable components in a larger platform architecture. They're the ones that build workflows that abstract away engine-specific details. They're the ones that invest in tooling that supports multi-IaC environments without creating operational chaos.

If your organization is still locked into Terraform, now is the time to architect for optionality. Start by evaluating OpenTofu migration paths. Decouple your pipelines from engine-specific CLI calls. Adopt a platform that treats IaC engines as implementation details, not strategic dependencies.

Because the next time a vendor changes their license, you want to be in a position to evaluate your options, not scramble for a migration plan.

DevOps & Automation Blogs

Featured Blogs

Streamline your Workflows with Environment Management

Closing the Gap Between CD and IaC

Blueprint-Driven by Design

Full Lifecycle Control

Governance Built In

From Portal to Platform

Harness Ships Five Capabilities to Power Confident Releases at AI Speed

What Harness Is Shipping

Coordinate multi-team releases without the war room

Know when to stop — automatically

Ship code and schema changes together

Roll out features gradually, measure what actually happens

From Deployment to Verified Outcome

Release Becomes a System, Not a Scramble

When Faster Code Starts to Break the Delivery System

The Emerging “Velocity Paradox”

Why the Delivery System Is Straining

What Organizations Should Do Next

1. Standardize delivery foundations

2. Automate quality and security checks earlier

3. Build guardrails into the release process

4. Remember measurement, not just automation

The Next Phase of AI in Software Delivery

Latest Blogs

Your AI Agents Are Only As Good As Your Data

The Five-Minute Demo Problem

Agent Quality Has Dimensions

Correctness: Ontologies Turn Silent Errors Into Loud Ones

Groundedness: The Relationship Graph Is the Citation Layer

Safety: Access Control at the Data Layer

Trajectory: Guided Navigation vs. Blind Exploration

The Dispatch Table Pattern

Performance: Aggregation Belongs at the Data Layer

These Dimensions Reinforce Each Other

The Investment That Compounds

Further Reading

Why Connected Platforms Will Power the Next Generation of AI in Engineering

AI does not just need data. It needs connected context.

This is where platform engineering becomes strategic

A portal alone is not enough

The real opportunity is a living knowledge layer

The next generation of AI in engineering will depend on system design

What leaders should do now

How to Build a Developer Self-Service Platform That Actually Works

What is Developer Self-Service?

Why Developer Self-Service Matters Now

Choosing the Right Candidates for Developer Self-Service

Core Components of Developer Self-Service

Golden Paths and Software Catalogs

Policy as Code Guardrails

Metrics, Scorecards, and Audit Trails

A 90 Day Plan to Launch Developer Self-Service

Days 0–30: Lay the Foundation

Days 31–60: Scale and Measure

Days 61–90: Standardize and Govern

Governance Without Friction

Developer Self-Service Best Practices

Ship Faster With Guardrails: Start With Harness IDP

Developer Self-Service: Frequently Asked Questions (FAQs)

How does developer self-service reduce toil without creating chaos?

Can we introduce an internal developer portal without disrupting our existing CI or Jenkins setup?

How do we prove developer self-service ROI and compliance to leadership?

What happens when developers need something outside the standard templates?

How quickly will we see results from a developer self-service rollout?

What tools are essential for a modern developer self-service platform?

How to Implement Self-Service Infrastructure Without Losing Control

What is Self-Service Infrastructure?

Core Building Blocks of Self-Service Infrastructure

Standardized Templates and Modules

Guardrails as Code

Environment Catalog

Internal Developer Portal (IDP)

Reference Architecture: From Portal to Pipelines to Policy

Internal Developer Portal as the Front Door

Infrastructure as Code Pipelines as the Execution Engine

Continuous Delivery Pipelines for Promotion

Policy as Code Engine for Guardrails

Scorecards and Dashboards for Visibility