Comments

Hacker News

hey HN, it's first time posting something here.

I’m building Kastor: Go CLI/declarative language/config for AI agents.

the motivation: agent definitions often end up spread across framework code, prompt files, tool files/mcps, platform UI settings, and env vars. that makes them hard to review, diff, reproduce or move.

Kastor is an attempt to put a source-of-truth layer above that.

right now the working proof of concept is narrow:

- .agent / .tool / .prompt files - HCL parser + validation - dependency/reference checks - LangGraph codegen - runnable weather example - runnable content scheduler example

the long-term direction is Terraform-ish:

- build: compile to framework code - plan/apply: reconcile hosted platform agents - state: track remote resources and detect drift

I’m deliberately not trying to build another agent runtime. the thing I’m trying to validate is whether agents need something closer to IaC: versionable, reviewable, declarative source of truth.

would appreciate any kind of feedback, especially on the language/design.

by weirdguy

works for me. terraform for agents? neat

by Leewen

thanks — that’s the direction. current version is still just validate + LangGraph codegen, but plan/apply/state is the part I’m trying to get to next

by weirdguy

The website is down?

by handfuloflight

oh, it's not, just root domain (non-www) without redirect

by weirdguy

The problem right now with something like this is you're trying to nail jello to a wall. People haven't figured out what an agent is yet, and trying to crystalize what people happen to be doing right now means in a few months, you're going to be obsolete.

by empath75

You mean Claude…

by reactordev

I agree with you

don't think the "agent" abstraction is stable enough to standardize the behavior/runtime layer yet.

thing I'm trying to test is smaller: is that possible to standardize the outer contract around agents?

what inputs does it accept? what outputs does it promise? what model does it use? what prompt/template does it depend on? what tools can it call? what target should it be built or applied to?

so here it is intentionally not trying to describe the full control loop or become a runtime. it's more like a source-of-truth layer for the parts that are already showing up everywhere, even if the runtime patterns keep changing underneath.

I might be wrong, but my bet is that the runtime layer will keep changing, while the need for reviewable/diffable agent contracts will not.

by weirdguy

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • hey HN, it's first time posting something here.

    I’m building Kastor: Go CLI/declarative language/config for AI agents.

    the motivation: agent definitions often end up spread across framework code, prompt files, tool files/mcps, platform UI settings, and env vars. that makes them hard to review, diff, reproduce or move.

    Kastor is an attempt to put a source-of-truth layer above that.

    right now the working proof of concept is narrow:

    - .agent / .tool / .prompt files - HCL parser + validation - dependency/reference checks - LangGraph codegen - runnable weather example - runnable content scheduler example

    the long-term direction is Terraform-ish:

    - build: compile to framework code - plan/apply: reconcile hosted platform agents - state: track remote resources and detect drift

    I’m deliberately not trying to build another agent runtime. the thing I’m trying to validate is whether agents need something closer to IaC: versionable, reviewable, declarative source of truth.

    would appreciate any kind of feedback, especially on the language/design.

    by weirdguy
  • works for me. terraform for agents? neat
    by Leewen
  • thanks — that’s the direction. current version is still just validate + LangGraph codegen, but plan/apply/state is the part I’m trying to get to next
    by weirdguy
  • The website is down?
    by handfuloflight
  • oh, it's not, just root domain (non-www) without redirect
    by weirdguy
  • The problem right now with something like this is you're trying to nail jello to a wall. People haven't figured out what an agent is yet, and trying to crystalize what people happen to be doing right now means in a few months, you're going to be obsolete.
    by empath75
  • You mean Claude…
    by reactordev
  • I agree with you

    don't think the "agent" abstraction is stable enough to standardize the behavior/runtime layer yet.

    thing I'm trying to test is smaller: is that possible to standardize the outer contract around agents?

    what inputs does it accept? what outputs does it promise? what model does it use? what prompt/template does it depend on? what tools can it call? what target should it be built or applied to?

    so here it is intentionally not trying to describe the full control loop or become a runtime. it's more like a source-of-truth layer for the parts that are already showing up everywhere, even if the runtime patterns keep changing underneath.

    I might be wrong, but my bet is that the runtime layer will keep changing, while the need for reviewable/diffable agent contracts will not.

    by weirdguy

Related stories