Kastor: A New Approach to Managing AI Agents with Declarative Specs

When AI Agents Meet Declarative Configuration

A new open-source project called Kastor has been gaining attention on Hacker News. It proposes an intriguing idea: borrowing from the proven playbook of Infrastructure as Code (IaC) to define and manage AI Agents using declarative specs — similar to how Terraform works.

The concept sounds simple, but it cuts right to the core pain points of modern AI Agent development: unpredictable behavior, poor reproducibility, and the difficulty of standardizing Agent management across teams. Kastor attempts to solve these problems through a software engineering lens.

From Terraform to AI Agents: Applying Declarative Thinking

Anyone familiar with DevOps knows Terraform's core philosophy: instead of manually provisioning cloud resources step by step, you declare the desired end state, and the tool automatically calculates the diff and drives reality toward that target. This "desired state" management model dramatically improves the reproducibility and maintainability of infrastructure.

Background: Terraform and the Rise of IaC

Terraform was released by HashiCorp in 2014 and is one of the most representative tools in the IaC space. The core idea of IaC is to describe infrastructure resources — servers, networks, databases — as code, making them versionable, reproducible, and automatically deployable. Terraform uses HCL (HashiCorp Configuration Language) as its declarative configuration language. Engineers define the "desired state," and the Terraform engine computes the diff between the current state (tracked in a state file) and the desired state, then automatically executes the necessary creates, updates, and deletes. This idempotent design significantly reduces operational risk. Today, IaC is a standard practice in DevOps and cloud-native engineering.

Kastor transplants this paradigm into the AI Agent world. Instead of writing extensive imperative code describing how an Agent should act, developers write spec files declaring what the Agent should be — covering capability boundaries, tool permissions, behavioral constraints, and expected outputs.

Understanding this shift requires clarifying the fundamental difference between declarative and imperative paradigms. Imperative programming requires developers to explicitly describe how to achieve a goal step by step — like a shell script executing server configuration commands one line at a time. Declarative programming requires developers to describe only the desired end state, leaving the execution path to the underlying engine.

Declarative programming is not a new concept — its roots trace back to logic programming languages like Prolog and functional languages like ML in the 1970s. SQL, introduced in 1974, marked the first large-scale industrial success of the declarative paradigm: users declare what data they want, and the query optimizer decides the best execution plan. In the cloud-native era, Kubernetes brought declarative configuration to container orchestration in 2014. YAML-defined resources like Pods and Deployments follow the "describe desired state" principle, with the control plane's Reconciliation Loop continuously driving actual state toward desired state — a Controller Pattern that has become a cornerstone of modern cloud-native system design. Applying this thinking to AI Agents means developers no longer need to hand-write complex scheduling logic; the framework handles runtime coordination. This shift is particularly valuable for building reliable, auditable AI systems.

However, migrating state convergence mechanisms to AI Agents comes with unique challenges. Terraform's convergence relies on deterministic API calls — a cloud resource either exists or it doesn't, and diff calculation is precise. LLM outputs are probabilistic: the same spec can produce very different behavior across runs. An Agent's "state" is difficult to quantify precisely like a server IP address. Tool call side effects are often irreversible and cannot be simply rolled back like infrastructure resources. As a result, declarative specs for AI Agents are closer to "constraint declarations" than "state declarations" — they define behavioral boundaries and capability scopes rather than precise execution outcomes. This requires framework designers to rethink what "convergence" means in a stochastic system.

Core Problems That Declarative Specs Address

Most mainstream AI Agent development today relies on Prompts scattered throughout the codebase, ad-hoc tool registrations, and hardcoded flow control logic. This creates several thorny engineering problems.

The Reproducibility Problem

Agent behavior depends heavily on Prompt wording, model version, tool configuration, and many other variables. When these configurations are scattered across imperative code or arbitrary strings, achieving consistent behavior across environments and over time becomes extremely difficult. Declarative specs consolidate and structure these key elements in one place, fundamentally improving reproducibility.

Team Collaboration and Version Control

Just as Terraform configuration files can be committed to Git and reviewed via pull requests, Kastor-style Agent specs support version-controlled management. Team members can clearly track every change to an Agent's definition and understand how its behavior has evolved over time — which is especially critical for governing AI systems in production.

From "Black Box" to "Auditable"

Explicitly declaring an Agent's capabilities and constraints makes previously opaque Agent behavior visible and reviewable. This is particularly important in enterprise contexts. As AI systems enter heavily regulated industries like finance, healthcare, and law, AI Governance has become a standalone compliance concern. The EU AI Act, which came into force in 2024, requires high-risk AI systems to be auditable, transparent, and subject to human oversight. The NIST AI Risk Management Framework similarly emphasizes explainability and accountability chains. Declarative Agent specs align well with these compliance requirements: explicitly declared tool permissions map to the principle of least privilege; versioned spec changes map to audit log requirements; structured constraint definitions map to risk assessment documentation needs. Compliance and security teams can review the spec files directly without needing to understand the underlying implementation code — significantly reducing governance overhead.

Industry Trends in the AI Engineering Wave

Kastor's emergence is not an isolated phenomenon — it's a reflection of the broader AI Engineering wave.

Background: The Real Engineering Challenges of AI Agents

AI Agents are AI systems capable of autonomously perceiving their environment, planning steps, and calling external tools to complete complex tasks — exemplified by frameworks like LangChain, AutoGPT, and CrewAI. As LLM capabilities have rapidly advanced, Agents have moved from lab concepts toward production deployment at an accelerating pace. However, the engineering challenges of production-grade Agents far exceed model capability alone: Prompt versioning chaos causing behavioral drift, lack of fine-grained tool permission controls, no unified orchestration standard for multi-agent collaboration, and severely insufficient debugging and observability tooling. This has propelled AI Engineering as a distinct discipline, rapidly filling in the toolchain from Prompt management and evaluation frameworks to Agent orchestration. The declarative specs that Kastor explores are an important part of building this ecosystem.

The current AI Agent engineering ecosystem is undergoing a critical transition from "works" to "works well." At the Prompt management layer, tools like LangSmith and PromptLayer offer version tracking and A/B comparison. At the evaluation layer, frameworks like RAGAS and DeepEval attempt to quantify Agent behavior quality. At the observability layer, OpenTelemetry is expanding into LLM call chains, with tools like Langfuse and Helicone providing tracing and monitoring. At the orchestration layer, frameworks like LangGraph, Dify, and AutoGen explore different models of Agent collaboration. Yet the overall toolchain remains fragmented — there's no unified abstraction standard analogous to Kubernetes for container orchestration. This is precisely the gap that declarative spec projects are trying to fill.

As Agents move from demo to production, the industry is increasingly recognizing that simply piling up Prompts and call chains is unsustainable. Mature software engineering methodologies must be brought in.

Advantages and Trade-offs of the Declarative Approach

The greatest advantage of the declarative approach is separation of concerns — developers focus on "what they want," and the framework handles "how to achieve it." This reduces cognitive overhead and improves configuration portability. But the flip side is that declarative abstractions often sacrifice some flexibility. When an Agent requires complex dynamic decision logic, pure declarative expressiveness may fall short.

How to elegantly introduce imperative "escape hatches" will be a key design challenge for tools like this. Escape hatches are an important pattern in mature framework design — when high-level abstractions can't satisfy a specific need, the framework intentionally preserves low-level access interfaces. React's useRef, Kubernetes' Custom Resource Definitions (CRDs), and Terraform's provisioner are all classic examples. Overly closed abstractions force users to bypass the framework entirely; well-designed escape hatches allow developers to enjoy high-level convenience while dropping down to imperative control when necessary. For declarative AI Agent frameworks, balancing abstraction depth with flexibility will directly determine whether the framework can cover a wide enough range of real-world scenarios.

The Reality of an Early-Stage Project

Objectively speaking, based on the limited early discussion on Hacker News, Kastor is still a project in the exploratory stage. The concept it proposes is commendable, but the true value of a declarative framework only becomes apparent through extensive real-world use. Whether the abstractions are appropriate, whether they're expressive enough, and whether the ecosystem can mature — all of this remains to be tested by time.

Conclusion: The Future of "Agent as Code"

Regardless of how far Kastor itself goes, "managing AI Agents with declarative specs" is a direction the entire industry should take seriously. As AI Agents gradually become standard components of software systems, the engineering standards and governance tools to match them have become an urgent need.

From Infrastructure as Code to today's exploration of "Agent as Code," mature software engineering paradigms are extending into the AI domain at an accelerating pace. Declarative configuration took a decade to evolve from an emerging concept to an industry standard in the infrastructure world — the engineering path for AI Agents may require similar time to mature. But the direction is already clear. For teams building production-grade AI systems, staying closely attuned to the evolution of these engineering tools may prove to be a competitive advantage when it comes time to make technology decisions.