Constrained Creativity

Why People Wanted It

An agent can be capable and still be unreliable when it must act without supervision. In high-stakes work, the tension is real: a fixed playbook is easy to inspect but misses situations no one anticipated; arbitrary generated code can handle more cases, but is harder to verify. The problem is not simply whether an agent can reason. It is how much freedom its actions should have.

So the real question is: can you leave the agent room to choose a response without leaving it room to do anything at all?

The Core Move

Give the agent a task-specific abstraction, express it as a domain-specific language (DSL) of approved operations, and let the agent compose those operations into a workflow a specialized runtime can check and execute.

The essential boundary is: the agent chooses a program from a designed action space, rather than writing arbitrary code or issuing arbitrary low-level actions.

Why the Abstraction Sets the Freedom Boundary

Now the version for readers who want more of the machinery: the abstraction determines which distinctions the agent can express, so it sets both the useful flexibility and the limits of the DSL.

An abstraction hides implementation details while retaining the concepts that matter to the task. For network red-teaming, “scan a network” or “infect a host” is a more useful agent-level operation than a shell command: the runtime can own low-level execution and network state, while the agent chooses a task-relevant action. In incident analysis, the useful vocabulary instead concerns hypotheses, comparisons, and evidence ranking. A good abstraction is therefore not just a shorter command set; it selects the objects and actions that make sense for the domain.

The design tradeoff is structural. A narrow vocabulary is easier to understand and verify, but rules out workflows that need missing operations. A broad vocabulary can cover more cases, but makes the action space harder to inspect and control. The target is the least freedom sufficient for the task, with room to expand the abstraction when genuine requirements demand it.

Why a DSL Constrains Actions, Not Just Output Format

Here is the part that gets technical: a DSL constrains both the operations the agent may select and the legal ways it may compose them.

A schema can ensure that generated output is well-formed, but well-formed output can still request the wrong analysis. A DSL goes further: its operators represent domain-approved work, and its composition rules define what counts as a valid workflow. The agent can still decide which investigation to run, but each step must be expressible in that vocabulary and accepted by its rules.

That makes the DSL a language for reasoning as well as execution. The model plans in meaningful domain operations; a specialized runtime interprets those operations using the right underlying tools, such as queries, statistical analysis, or stateful event processing. The model need not be integrated with or jointly trained alongside a symbolic reasoner: the boundary comes from the action space and runtime. But what workflow shapes should that language allow?

Why Workflow Shape Determines What the Agent Can Express

Now for the deeper constraint: the same operation vocabulary can support different kinds of control flow, and each exposes a different kind of choice to the agent.

A sequential chain lets one result feed a later step. A parallel directed acyclic graph (DAG) can run independent operations as branches and combine their results. An iterative workflow can repeat analysis as intermediate results change what should happen next. A finite-state machine makes the agent’s progress explicit through states and permitted transitions. These are not merely different syntaxes: they determine whether the agent can order, branch, revisit, or transition among operations.

For a troubleshooting DSL, for example, a workflow might find candidate causes, compare a time window with a baseline, score the evidence, then rank the candidates. That chain is one possible composition, not a fixed playbook: another incident can call for a different permitted workflow. The runtime can execute the chosen structure, while the DSL’s rules bound the available steps and combinations. How much flexibility is enough before the workflow itself becomes difficult to check?

Minimal Causal Code

This toy runtime makes the boundary visible: the model proposes operation names and arguments, while Python dispatches only registered operations. It illustrates a sequential workflow, not a complete DSL parser or verifier.

def compare_windows(data, current, baseline):
    return {
        key: data[current].get(key, 0) - data[baseline].get(key, 0)
        for key in set(data[current]) | set(data[baseline])
    }


def rank_changes(changes):
    return sorted(changes.items(), key=lambda item: abs(item[1]), reverse=True)


OPS = {
    "compare_windows": compare_windows,
    "rank_changes": rank_changes,
}


def run(workflow, context):
    value = None
    for operation, arguments in workflow:
        if operation not in OPS:
            raise ValueError(f"operation not allowed: {operation}")
        inputs = {**context, **arguments}
        if value is not None:
            inputs["changes"] = value
        value = OPS[operation](**inputs)
    return value


workflow = [
    ("compare_windows", {"current": "10am", "baseline": "9am"}),
    ("rank_changes", {}),
]

The whitelist is the key causal boundary: the proposed workflow cannot dispatch an operation that the runtime has not registered. A production DSL also needs to define valid arguments, types, composition rules, and any domain-specific safety checks.

What You Gain, and What You Lose

You gain a smaller, more legible action space: the agent can choose and compose meaningful operations, while execution stays with a domain-specific runtime. That makes the workflow easier to inspect than arbitrary generated code and more adaptable than a fixed playbook.

You do not get reliability merely by calling something a DSL. The abstraction can omit an operation the task needs, or admit combinations that are legal syntactically but poor for the task. A constrained agent is less flexible than an unrestricted one by design; expanding its vocabulary restores capability but also expands what must be checked. The practical question is not whether to constrain, but where to draw the boundary between useful choice and uncontrolled action.

Quiz

What is the central boundary in Constrained Creativity?

The runtime makes every possible agent action safe without defining an action space.

The agent composes approved domain operations; it does not receive unrestricted authority to write arbitrary code or issue arbitrary actions.

The agent follows one fixed workflow chosen in advance for every task.

The agent may produce any code as long as its output is valid JSON.

$ check