Ecosystem Spotlight: elastic/oblt-aw

Nov 10, 2026

Wiring an agentic workflow by hand into every repository works for one repository and falls apart at fifty. elastic/oblt-aw is an opinionated framework for GitHub Agentic Workflows that addresses this directly: shared, reusable routes live in one repository, small “client” workflows are installed automatically into consumer repositories, and a control plane decides whether each agent is allowed to run. It is aimed at platform and developer-productivity teams that need to roll out, tune and switch off agents across many repositories without chasing each one.

Why it’s awesome

Thin clients, central logic. Consumers hold only narrow-trigger files such as trigger-obs-aw-pull-request.yml, each of which calls an event-scoped orchestrator in the framework repository. The client template doc explains the split-trigger design: only the routes that match the GitHub event run, which keeps pull requests quiet. Improving an agent means changing it once in oblt-aw.

A checkbox dashboard as the on/off switch. Each repository gets a single pinned issue, [oblt-aw] Control Plane Dashboard, with one task-list entry per workflow. The get-enabled-workflows workflow reads it with only contents: read and issues: read, and the rules are fail-closed: no open dashboard issue means no gated workflow proceeds. Repository owners get a self-service control with no config file to edit. The dashboard guide describes the flow.

A shared prelude, enforced by CI. aw-prelude runs once per event family. It reads the dashboard, optionally loads bot allow lists for pull request and issue authors, and emits a proceed-by-workflow map. A validation script (validate_aw_workflow_prelude.py) checks that every route declares the shared-proceed input, so a new workflow cannot quietly skip the gate. A matching check covers aw-resolve-agentic-assets, which merges platform instructions with a consumer’s optional apm.yml so repositories can tailor an agent without forking it.

Multi-organization ownership. Per-organization configuration lives under config/<org-key>/, and checkboxes use compound ids like org:workflow-id. The multi-org design lets several teams share one catalog while a repository still sees one dashboard grouped by owner. A maturity model (stable, early adoption, experimental) labels each workflow so adopters know what they are opting into.

A release train with rollback. The release model separates development repositories, which follow @main and act as live canaries, from production repositories, which are pinned to a moving major tag. Promotion is a manual dispatch that runs the end-to-end suite first, then pushes an immutable audit tag and updates config/release-pointers.json. Rollback retargets the tag to the previous commit. The docs also record fail-closed rules: distribution will not write a pin for a tag that is missing on origin.

How it works

A repository is listed in its organization’s active-repositories.json.
The distribution workflow opens pull requests that install the client templates, substituting the right pin for the repository’s pin-class. If two organizations would install different files at the same path, it stops with an explicit conflict.
A sync job creates or updates the dashboard issue.
When an event fires, the client calls its orchestrator, the prelude evaluates the gates, and enabled routes run an agent, resolving instructions first through the assets workflow.

Reusable agents that are called across repositories have one extra requirement. Elastic’s sibling project docs-actions documents that cross-repository workflow_call use depends on inlined-imports: true, so the compiled lock file is self-contained. That detail is easy to miss and worth copying if you publish reusable agents.

Try it

oblt-aw is tailored to Elastic’s organizations, so treat it as a reference architecture rather than a drop-in package. The patterns transfer well:

Keep consumer workflows tiny and call a pinned reusable workflow centrally.
Use an issue with checkboxes as a fail-closed, auditable enablement switch.
Add a CI check that every agent route honors the gate.
Separate canary repositories (@main) from production (@v0), and rehearse rollback.

For a smaller example of the same idea, elastic/docs-actions publishes reusable documentation agents with example.yml caller templates and a table of the safe outputs each workflow may use.

Learn more

Explore elastic/oblt-aw, starting with its README and architecture overview, and see what a governed fleet of agents looks like. To build your own, start with GitHub Agentic Workflows.