Agentic Development with a Cognitive DSL YAML Interface

Asher Bond

Abstract

Agentic software development — an LLM agent that plans, generates, executes, validates, and packages work — needs a legible way to specify what the agent should do, distinct from the model that does it. We present a cognitive DSL: a small YAML notation in which a workflow is a composition of higher-order functions (HOFs), each HOF a named stage built from atomic functions, and every function declared as an explicit Input–Process–Output (IPO) triple. The notation is a direct, human-readable encoding of functional composition [1, 2, 3]; it makes an agent's plan inspectable, diffable, and re-runnable rather than buried in prose prompts. We present the notation, a worked "Hello, World in every language" specification, and its validate-and-retry loop. The contribution is the interface: a way to write agent workflows down as data an interpreter executes.

1. Introduction

Prompt-driven agents encode their plans implicitly, in natural-language instructions that are hard to inspect, version, or validate. This article gives the explicit alternative: write the plan as data. A workflow becomes a YAML document whose top level is an ordered list of HOF stages (planning, code generation, execution, validation, packaging), each stage a composition of atomic functions, and each function a declared Input–Process–Output triple. The agent interprets this specification rather than improvising from prose.

The design borrows nothing exotic. Organizing computation as higher-order functions over atomic functions is the standard functional-composition discipline [1, 2, 3]; expressing each unit as Input–Process–Output is the oldest decomposition in computing. The move is to make that structure the authored surface of an agent, so that a plan can be read, reviewed, and re-run deterministically.

2. Related Work

Functional composition. The notation's semantics are those of function-level programming [1], the modularity that higher-order functions and lazy composition provide [2], and functions as first-class values [3]. An HOF stage that sequences atomic functions is compose; a stage that applies one function across a list of languages is map; the retry loop is a bounded fixpoint.

LLM agents. The agents that interpret this DSL are transformer-based models [4, 5]. Their documented tendency to hallucinate [6] is precisely why the notation makes the validation stage a first-class, mandatory part of every workflow rather than an afterthought.

Reliability through re-adjudication. The DSL's continuous-improvement loop — generate, validate, refine, re-validate — is the same "produce candidates, then adjudicate" pattern that self-consistency [7] instantiates for reasoning; the DSL generalizes it to any stage with a checkable output.

3. The Notation

A workflow is a YAML document. Its grammar has three levels:

Project — names the goal and lists the ordered HOF stages.
HOF stage — a named phase with a declared Input, an ordered process of atomic functions, and an Output. Stages compose: one stage's Output is the next stage's Input.
Atomic function — the leaf unit, declared as type: atomic_function with explicit input, process, and output fields — an IPO triple. Two non-atomic leaf types exist: loop (a bounded retry over a condition) and user_action (a step requiring a human).

Writing the plan this way makes it data: it validates against the grammar, diffs across revisions, and executes deterministically under an interpreter, independent of the specific model that fills in each process.

4. Worked Example: "Hello, World" in Every Language

The following specification (abridged from the full document) shows the notation in use. It is [ILLUSTRATIVE] — it demonstrates the notation's shape, not a measured run:

project:
 name: "Hello World in Every Language"
 description: "Generate, execute, and validate 'Hello, World!' programs in multiple languages."
 steps: [planning_HOF, code_generation_HOF, execution_HOF, validation_HOF, packaging_HOF]

planning_HOF: # HOF stage: Input -> Process(atomic functions) -> Output
 input: "user_prompt"
 process:
 - identify_languages: { type: atomic_function, input: "user_prompt", process: "select_languages", output: "language_list" }
 - setup_project_structure: { type: atomic_function, input: "language_list", process: "create_folder_structure", output: "project_structure" }
 output: "project_plan"

validation_HOF: # the mandatory validate-and-retry stage
 input: "initial_execution_results"
 process:
 - validate_outputs: { type: atomic_function, input: "execution_logs", process: "check_output_for_hello_world", output: "validation_report" }
 - fix_errors: { type: atomic_function, input: "validation_report", process: "identify_and_fix_errors", output: "refined_code_files" }
 - continuous_loop:
 type: loop
 condition: "until all programs output 'Hello, World!' correctly"
 actions: [validate_outputs, fix_errors, reexecute_and_revalidate]
 output: "validated_code_files"

Every unit is an IPO triple; the stages compose left to right; the validation_HOF carries a bounded loop that re-runs until its condition holds. A retry budget bounds the loop in any real interpreter, so an unsatisfiable condition terminates in an explicit failure rather than spinning — the YAML condition states intent, the interpreter enforces termination.

5. Why an Explicit Notation

Three properties follow from writing the plan as composed IPO data rather than prose:

Inspectability. A reviewer reads the plan as a structured document, not as a paragraph of instructions.
Determinism at the seams. Stage boundaries are explicit Input/Output contracts, so the composition is reproducible even though each process may be model-filled.
Validation is structural. Because every stage has a declared Output, a validation gate attaches to any of them — the notation makes "check this step" a first-class move [7].

Evidence & Scope

The cognitive DSL is an interface, specified and worked end to end. It defines a notation: the plan is data an interpreter executes, and its value — inspectability, deterministic seams, structural validation — is a property of the notation, verifiable by reading it. Two contracts belong to the interpreter and the notation states them explicitly: each stage's Input/Output boundary, and a finite retry budget that makes the validation loop terminate on an unsatisfiable condition. "Cognitive DSL," "HOF stage," and "atomic function" are this corpus's terms for ordinary functional composition [1, 2, 3].

References

John Backus (1978). Can Programming Be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs. Communications of the ACM. [1977 ACM Turing Award Lecture]
John Hughes (1989). Why Functional Programming Matters. The Computer Journal.
Christopher Strachey (2000). Fundamental Concepts in Programming Languages. Higher-Order and Symbolic Computation. [Reprint of 1967 lecture notes]
Ashish Vaswani et al. (2017). Attention Is All You Need. Advances in Neural Information Processing Systems (NeurIPS). arXiv:1706.03762.
Tom B. Brown et al. (2020). Language Models are Few-Shot Learners. Advances in Neural Information Processing Systems (NeurIPS). arXiv:2005.14165. [GPT-3]
Ziwei Ji et al. (2023). Survey of Hallucination in Natural Language Generation. ACM Computing Surveys. arXiv:2202.03629.
Xuezhi Wang et al. (2023). Self-Consistency Improves Chain of Thought Reasoning in Language Models. International Conference on Learning Representations (ICLR). arXiv:2203.11171.