DEV Community: Tim Poschel

It’s Not an Agent Loop. It’s a Helix.

Tim Poschel — Tue, 11 Aug 2026 04:07:28 +0000

We keep talking about “agent loops.”

Observe → Think → Act → Reflect → Repeat.

The language is everywhere: papers, product demos, architecture diagrams. Clean, circular and easy to draw on a whiteboard.

But a loop is a closed system that tends toward equilibrium or oscillation. Information that isn’t deliberately carried forward gets lost or compressed into a thinner and thinner summary. After enough cycles, the agent is effectively starting over with a foggy memory of why it chose the path it’s on.

That’s not how durable intelligence compounds. What we’re actually building (or should be building) is a helix.

Each cycle still moves through observation, decision, and action. But the decisions and the data from that cycle are deliberately recorded. They don’t disappear into a context window that will later be truncated. They become structured information that the next cycle can consult, query, and build upon. The trajectory is no longer circular. It advances along an axis of accumulating knowledge.

A loop forgets. A helix remembers why. And this difference is not semantic. It changes the architecture.

In a pure loop, the state that survives is usually a summary, a plan update, or whatever fits inside the current context budget. Intermediate reasoning, discarded branches, partial observations, and the exact justification for a choice three steps ago are treated as disposable. The system is forced to re-derive what it already knew.

In a helical design, the full decision-and-data history is treated as first-class material. It can be indexed, retrieved, summarized at multiple levels of abstraction, and still remain available in its original form when needed. The agent doesn’t just “remember” outcomes; it can inspect the reasoning that produced them.

The practical consequences show up most clearly on long-horizon tasks:

A looping agent can lose the thread of why a particular approach was chosen after enough cycles.
A helical agent can still surface the original decision trace, the data that justified it, and the outcomes that followed—then use that substrate for the next decision.

This also reframes how we think about memory and reflection. Instead of episodic retrieval bolted onto a looping core, the entire history becomes a continuously growing, traversable structure. The agent can move forward (what should come next) and backward (why are we here) with higher fidelity.

We’re still early. Most production “agents” today are loops with better tooling and longer context windows. The helical version requires deliberate investment in persistent decision logs, multi-resolution memory, and interfaces that let the model treat its own history as queryable information rather than disposable intermediate tokens.

But the distinction is worth making precise. Because the systems that compound intelligence over dozens or hundreds of cycles won’t be the ones that simply go around again. They’ll be the ones that carry the weight of every previous turn forward.

Why SREL Matters for Agent Governance

Tim Poschel — Mon, 10 Aug 2026 15:02:20 +0000

Most conversations about AI agents focus on capability: what the agent can do, which tools it calls, how it reasons. Far less attention is paid to a harder question — how do we make the risk of that agent machine-readable and comparable?

This is where SREL becomes complementary to capability languages like ACEL.

Capability vs Risk: Two Missing Standards

Concern	What we need	Current state
What the agent is allowed / designed to do	Declarative capability contract	Emerging (ACEL, Agent Spec, etc.)
How risky that agent is in context	Structured, comparable risk output	Almost entirely free-form (PDFs, slides, spreadsheets)

ACEL answers the first question cleanly: five aspects + autonomy modal + oversight rules, expressed as a versioned contract.

SREL answers the second: a normative grammar so that risk assessments become data instead of documents.

Without the second half, governance stays manual and non-scalable.

The Gap SREL Closes

Today a model risk or agent risk assessment usually ends up as:

A long PDF
A spreadsheet with colored cells
A slide deck for a review committee

None of these can be:

Ingested by a monitoring system
Diffed across versions
Compared across vendors
Automatically escalated when a threshold is crossed
Linked structurally to the controls that are supposed to mitigate them

SREL turns the assessment into a conformant document with required sections, typed values, and semantic invariants. Downstream systems can consume it the same way they consume OpenAPI or SBOM files.

Geometric Structure, Not Just Another Schema

SREL is not “yet another YAML schema for risk.”

It is built on a geometric substrate:

9 dyadic groups × 6 compositional periods = 54 named risk primitives
Each primitive sits at a fixed coordinate
Scores live on an n-simplex decomposition
A meta-condition veto (KILL, SAF, HITL, AUT, TRU, MAN) can collapse the entire composite to zero if structural prerequisites fail

This gives the language two useful properties:

Comparability — two assessments of different systems can be placed in the same coordinate space.
Control linkage — the Controls Exchange profile places controls at the same coordinates as the risks they address. No external mapping table required.

That last point is rare. Most control frameworks (OSCAL, etc.) and risk frameworks live in separate conceptual spaces. SREL deliberately co-locates them.

How This Complements Declarative Agents

Imagine an agent defined in ACEL:

agent research_assistant {
  autonomy: SUPERVISED
  ...
  oversight high_stakes {
    trigger: UNCERTAINTY_ABOVE 0.3
    action: ASK_APPROVAL
  }
}

That contract tells us what the agent is and how it should be governed at runtime.

A corresponding SREL document can tell us how risky the current deployment of that agent is, under real conditions, with a machine-checkable composite score and a clear record of which primitives are driving the risk.

The two artifacts answer different questions:

ACEL → “What is this agent supposed to be and how is it constrained?”
SREL → “Given the current context, how risky is it actually behaving / performing?”

Together they form a more complete governance loop:

Declare capability and oversight (ACEL)
Assess risk in a structured, comparable form (SREL)
Feed the risk output back into monitoring, policy, or human review
Update the capability contract or the runtime thresholds when needed

Practical Implications

If you are building:

Agent platforms → You can emit SREL documents as part of continuous evaluation
Model risk management → You finally have an interchange format instead of proprietary report formats
Monitoring / observability → You can alert on structured bands (WATCH → DRIFT → ELEVATED → CRITICAL) instead of parsing prose
Controls / compliance → You can place controls at the same coordinates as the risks they mitigate

The language is deliberately open (CC0 for the specification text) and designed for downstream consumption rather than for any single vendor’s scoring engine.

Closing Thought

Capability languages make agents describable.

Risk languages make agents governable at scale.

SREL is an attempt to give the industry the second half of that equation in a form that machines can actually use.

If ACEL (or similar contracts) becomes the way we declare what an agent is, SREL is a strong candidate for how we exchange what its residual risk looks like.

Further reading

SREL specification & grammar: github.com/srel-spec/srel
Website: srel.net
Related capability language: github.com/srel-spec/acel

Declarative AI Agents: Spec Once, Generate Everywhere with ACEL

Tim Poschel — Mon, 10 Aug 2026 13:32:00 +0000

Most agent frameworks still force you to write imperative code: wire tools, manage memory, hard-code oversight logic, and re-implement the same patterns for every new runtime. The result is brittle agents that are hard to review, version, audit, or port.

A cleaner path is emerging: treat the agent as a declarative contract.

What is ACEL?

ACEL (Agent Capability Expression Language) is a small, focused language for defining AI agents. It is built on the Rectified Pentachoron Framework (RPF) and models an agent as exactly five aspects plus a global autonomy modal:

Aspect	Role	Neglect pathology
telos	The objective pursued	Aimless reactivity
world_model	Present apprehension of environment state	Ungrounded action (hallucination)
memory	State retained across time	Amnesia
deliberation	Mapping situation → action	Thrashing / myopia
actuation	Effecting change on the environment	Paralysis

Autonomy is not a sixth aspect. It is a modal that qualifies every aspect (supervised perception, supervised deliberation, etc.). Oversight rules sit alongside it as first-class triggers (uncertainty thresholds, irreversible actions, cost limits, etc.).

A minimal example looks like this:

agent research_assistant {
  autonomy: SUPERVISED

  telos {
    goal: ACHIEVE "comprehensive_report" AND MAINTAIN "factual_accuracy"
    priority: HIGH
  }

  world_model {
    grounding: REQUIRED
    percept web_search { type: RETRIEVE protocol: MCP freshness: 1h }
  }

  memory {
    type: HYBRID
    store short_term { capacity: 10000 ttl: 1h retrieval: RECENCY }
    store long_term  { capacity: 1000000 retrieval: RELEVANCE }
  }

  deliberation {
    mode: HYBRID
    plan   { strategy: HIERARCHICAL depth: 4 replan_on_failure: true }
    decide { strategy: MONTE_CARLO_TREE_SEARCH risk: 0.4 explore: 0.2 }
    reflect { trigger: ON_ERROR over: long_term }
  }

  actuation {
    effect document_store { type: MODIFY protocol: REST permissions: READ, WRITE }
  }

  oversight high_stakes {
    trigger: UNCERTAINTY_ABOVE 0.3
    action: ASK_APPROVAL
    escalate_to: lead
  }
}

The language enforces clean separations (raw data percepts are read-only; effects are write; reflection must bind to a declared memory store) and produces a conformance report against the five-aspect basis. The .acel file becomes the single source of truth — versionable, reviewable, and enforceable in CI.

From Spec to Artifacts: acel-generator

Writing the contract is only half the story. acel-generator (OpenAPI-Generator-style tooling for ACEL) turns that contract into concrete artifacts.

Pipeline:

.acel  →  parse + validate + framework conformance  →  intermediate representation (IR)  →  generators  →  artifacts

Current built-in generators include:

langgraph — LangGraph / LangChain-shaped Python package (agent, memory, tools, oversight)
markdown — Agent card (AGENT.md) + Mermaid architecture diagram
ossa — OSSA-style agent contract YAML
pytest — Basic invariant test suite
a2a — Agent2Agent Agent Card (.well-known/agent-card.json) for discovery and delegation
mcp — MCP tool manifest (mcp.json) with percepts as read tools and effects as write tools (plus destructiveHint annotations)

Governance details that current interoperability protocols do not express (autonomy level, oversight, grounding, retention shape) are emitted under namespaced extensions so the gap stays visible rather than being papered over.

Design principles of the generator:

The spec is the contract — generators map declared aspects; they invent no semantics.
Fail closed on validation.
Autonomy and oversight are first-class in every runtime generator.
Memory generators respect durability, resolution, and recording decisions.
Extensible via plugins and Jinja templates.

Why this matters

Governance as code — The same file that describes the agent also drives CI gates and runtime policy.
Interoperability without loss of intent — A2A skills and MCP tools are generated from the same percept/effect split.
Portability — One contract, multiple scaffolds (LangGraph today; others tomorrow).
Auditability — Every generated artifact can be traced back to a versioned, validated ACEL document.

ACEL is deliberately not a runtime. It is the contract that binds the layers you already run (agent loop, control plane, gateway, tools/MCP, memory). Author-time validation shifts left; runtime enforcement compiles autonomy and oversight into gateway rules.

Getting started

Language & validation: https://github.com/srel-spec/acel
Generator: https://github.com/srel-spec/acel-generator

Both are MIT-licensed (with a narrow patent non-assertion on the language itself). The projects are early (alpha), but the conceptual clarity is already strong.

If you are tired of re-implementing the same agent skeleton for every framework, try writing the contract once and generating the rest. Declarative agents are not just cleaner code — they are a practical step toward agents that are governable, auditable, and portable by design.

full docs: https://docs.srel.net