Orc (working name) - auditable and declarative AI workflow

**I’m building a small “Orchestration as Code” repo for LLM workflows. Does this concept make sense?** I’m building a small “Orchestration as Code” repo for LLM workflows. Does this concept make sense? I’ve been working on an early project called ORC, short for Orchestration as Code. I’m at the stage where I’m mainly trying to gauge whether the concept is interesting/useful to other people, especially people running local models, Ollama, llama.cpp, LM Studio, MCP tools, or mixed local/cloud workflows. The basic idea is: Instead of building LLM workflows as Python orchestration soup, or wiring them together in a visual tool, ORC lets you describe workflows declaratively in .orc files. Roughly: Terraform-ish workflow definitions, but for LLM agents and tool use. A workflow can define things like: \- agents \- models/providers \- tools \- schemas \- inputs \- ordered execution steps \- validation rules \- output artefacts The goal is not to build a magical autonomous agent framework. The goal is more boring. make LLM workflows easier to read, version, review, validate, and run repeatedly. A rough example of the kind of thing I’m aiming for: `agent researcher:` `provider: ollama` `model: gpt-oss:20b` `schema Report:` `type: json` `path: "report.schema.json"` `workflow dockerReport:` `input:` `docker_status: string` `step analyse:` `agent: researcher` `input: docker_status` `produces: Report` The runtime executes the steps, validates outputs against schemas, captures artefacts, and gives you a clearer trail of what happened during a run.Some things I’ve been experimenting with: \- local Ollama agents calling MCP tools \- structured report generation \- validating model outputs with JSON Schema \- Docker/container status summarisation \- simple multi-step research/editorial workflows \- publishing/posting via MCP tools \- mixing local and cloud models depending on the step This is still early, and the repo is not something I’d call polished or production-ready yet. I’m mostly trying to understand whether this direction is worth hardening further. What I’d really like feedback on: \- Does the “Orchestration as Code” concept resonate? \- Would a declarative DSL for LLM workflows be useful to you? \- Is this solving an actual pain point, or is it just a neat abstraction? \- What would you expect to see in the repo before taking it seriously? \- Are there existing projects that already cover this well? Would you prefer this as a standalone runtime, a Python library, a CLI tool, or something else?I’m especially interested in feedback from people who are already stitching together local models, tools, scripts, and structured outputs. At this stage I’m not trying to sell anything. I’m trying to find out whether the concept and repo are worth developing further, or whether this is just a cool but niche tool for my own workflows. I'm close to making the repo public and allowing people to use it if there's any value!