Governing Agent-Generated Workflows in Minimal Harnesses

An agent that creates its own workflow also creates new places where controls need to apply. A budget or permission check on the original task is not enough unless we know what happens when that task delegates work.

Imagine a coding agent allowed to edit one project and run its tests, but not deploy it. It decides to create a research helper and a test helper. We may want that flexibility without giving either helper deployment access or a fresh spending allowance. The important question is which restrictions follow the work, and which checks belong only to a particular role.

What JAZ makes programmable

Harness as a Language introduces JAZ, a framework where a model generates a function's executable body when it is called. That code can invoke further model-generated functions. The surrounding harness, the software coordinating model calls and tools, exposes workflow construction through this recursive interface.

The authors demonstrate long-running assistance and continual prompt-and-skill improvement on StuLife and AppWorld. The latter changes solver instructions and skills, not model weights.

For governance, the useful detail is control scope. JAZ describes scoped hooks that follow recursive calls and local hooks that do not. Its example shares one budget across descendants while keeping a return-type check local to the parent.

The September 2026 preprint evaluates GPT-5.4-family configurations, not current frontier coverage. Its AppWorld adaptation uses task feedback throughout the sequence; one comparator stops learning after the first tenth. Results vary across runs. These are bounded performance experiments, not evidence that hooks are non-bypassable security controls.

Which controls should follow the work?

A local check is not inherently a mistake. The parent might return a report while a helper returns a list of filenames. Requiring both to produce the same output type would be unhelpful.

A deployment restriction is different. In our example, creating a helper should not become a way to acquire deployment authority. Likewise, a task-wide spending limit should not silently restart for each child.

This gives us three questions to ask of any programmable agent workflow:

• Which requirements apply to every descendant, such as approved access and total resource limits?
• Which requirements belong to a specific role, such as its output format?
• Which component enforces each requirement, and can generated code change or bypass it?

Those are WTK's questions prompted by the design, not security conclusions reported by the paper.

What this adds to WTK's catalog and compilation questions

Our catalog approach describes an agent or team before deployment. Compilation connects that description to the capabilities and controls available in a target runtime. Agent-generated workflows raise a further question: what parts of the work may be created dynamically without changing the approved scope?

A useful catalog description could distinguish permission to delegate from permission to grant access. It could name requirements that must apply across the whole task and those specific to a role. The compiler would then need a supported way to express those requirements in the target environment. Where that support is absent or unverified, the limitation should remain visible rather than becoming an assumed guarantee.

This extends our discussion of checking permissions after agent changes. The narrower issue here is inheritance during execution: whether a newly created helper remains inside the required limits. It also depends on what the target runtime actually provides, not on controls we imagine every harness exposes.

We have not tested this behavior in WTK. Establishing it would require evidence about descendant actions and the controls actually enforced, including blocked actions, not just a successful parent result. A framework, model or runtime change could alter that conclusion.

Our takeaway: dynamic workflow construction and independent governance are compatible design goals. The next question is how to preserve required controls when the agent chooses the workflow, without unnecessarily fixing every step in advance.

Source

Zhening Li and colleagues, Harness as a Language: A Minimalist Agent Framework With Maximal Expressivity, arXiv:2609.26891v1, September 22, 2026. The framework and experiment results are the authors'. The catalog and control-inheritance questions are WTK's interpretation, following our research method.