Operon v0.18: Pattern-First Skills

1. What Felt Missing After v0.17

The strongest feedback I got after the epistemic release was also the fairest: operon still exposed too much of its formal vocabulary directly. I like that vocabulary. It makes the architecture precise. But most engineers do not wake up wanting to think in optics, coalgebras, or epistemic partitions. They want to know whether a workflow gets safer, cheaper, easier to inspect, or easier to reconfigure.

That pushed the next release in a much more practical direction. Instead of adding another theoretical layer, v0.18 adds a thinner public layer on top of the existing substrate. The point is not to remove the structure. The point is to let people start from the useful pattern and only descend into the structure when they actually need it.

2. The New Pattern-First Front Door

The first part of v0.18 is a new public layer in operon_ai.patterns. It adds three simpler entry points:

• advise_topology(...) for architecture guidance from task shape, tool count, and error tolerance.
• reviewer_gate(...) for the common one-worker-plus-reviewer pattern.
• specialist_swarm(...) for centralized specialist decomposition.

from operon_ai import advise_topology, reviewer_gate, specialist_swarm

advice = advise_topology(
    task_shape="sequential",
    tool_count=2,
    subtask_count=3,
    error_tolerance=0.02,
)

gate = reviewer_gate(
    executor=lambda prompt: f"EXECUTE: {prompt}",
    reviewer=lambda prompt, candidate: "safe" in prompt.lower(),
)

swarm = specialist_swarm(
    roles=["legal", "security", "finance"],
    workers={...},
)

What I like here is that the objects still carry the formal shape underneath. The wrappers expose .diagram and .analysis. So this is not a second system. It is a friendlier entrance to the first one.

3. Skill Organisms

The second part of the release is the piece I care about most: a runtime for skills that behaves more like a small organism than a single prompt wrapper. A skill can now be assembled out of named stages. Some stages can be deterministic handlers. Some can bind to a fast model for fixed classification work. Others can bind to a deeper model for fuzzier planning.

This is implemented through skill_organism(...), SkillStage, and TelemetryProbe. The result is a runtime where model choice becomes part of the structure instead of something scattered across handwritten scripts.

from operon_ai import MockProvider, Nucleus, SkillStage, TelemetryProbe, skill_organism

fast = Nucleus(provider=MockProvider(...))
deep = Nucleus(provider=MockProvider(...))
telemetry = TelemetryProbe()

organism = skill_organism(
    stages=[
        SkillStage(name="intake", role="Normalizer", handler=lambda task: {"request": task}),
        SkillStage(name="router", role="Classifier", instructions="Return a deterministic routing label.", mode="fixed"),
        SkillStage(name="planner", role="Planner", instructions="Use the routing result to propose the next action.", mode="fuzzy"),
    ],
    fast_nucleus=fast,
    deep_nucleus=deep,
    components=[telemetry],
)

result = organism.run("Customer says the refund never posted.")

The practical value is not just that this looks nicer. It means you can add pieces like telemetry, review, or later health mechanisms without rewriting the skill itself. The structure is explicit, but the public API is no longer hostile to normal engineering use.

4. Why v0.16 Matters in Retrospect

I do think it is relevant to mention v0.16 here, even though it was a smaller release and I did not give it its own post at the time. v0.16 added the OpenAI-compatible provider path and generally made the Nucleus provider layer more practical to use across backends.

At the time, that felt like a pragmatic integration improvement. In retrospect, it was also the bridge to v0.18. The new skill runtime only becomes useful because stages can bind to real provider-backed nuclei instead of being trapped in the old pedagogical BioAgent mock path.

5. Examples and Spaces

The release adds two practical entry points to the examples:

• examples/68_pattern_first_api.py for the new thin wrappers.
• examples/69_skill_organism_runtime.py for provider-bound, multi-model skills.

I also retuned the two epistemic Hugging Face Spaces around this more practical entry path. The Epistemic Space now leads with a Pattern Advisor, and the Diagram Builder now starts from useful presets like reviewer gate and specialist swarm instead of making people type raw diagrams first.

6. Validation

The package is also now published as 0.18.0 on PyPI. That matters less as a badge than as a signal that the pattern-first layer is no longer just sitting on a branch.

7. The Real Change

I do not think the real story of v0.18 is “we added three helpers.” The real story is that operon is starting to separate its internal precision from its external ergonomics.

That is a necessary move if the framework is going to become useful outside the subset of people, myself included, who enjoy the substrate for its own sake. The structure still matters. The epistemic layer still matters. But the next phase of the project has to be about making those ideas easy to use in a workflow before asking anyone to admire the mathematics underneath it.

Code and release: github.com/coredipper/operon, operon-ai on PyPI, operon-epistemic, operon-diagram-builder