oblt-aw (elastic/oblt-aw) is an opinionated shared framework for GitHub Agentic Workflows: reusable routes, thin clients distributed automatically to repos, and a control plane to turn workflows on or off (dashboard, sync, distribution, shared prelude).
Today many teams still wire each agent by hand in every repo (local workflow → gh-aw-*.lock.yml). That does not scale. We want to mitigate:
- Copy-paste setup in every repo (triggers, secrets, permissions).
- No shared on/off switch, so fleet behavior drifts.
- Expensive updates — chase N repos to change the same agent.
- Slow rollouts — every repo reinvents install and enablement.
- Unsustainable management as repos and agents grow.
oblt-aw keeps routing and management in the framework; agents still run from pinned upstream locks. Clients are distributed automatically, so entry points stay centralized and sustainable.
Background: state-of-the-art analysis for agentic workflows.
In a very simplified way:
- Clients (
trigger-oblt-aw-*.yml) are installed using an automated distribution (client template). - On a matching event, the client calls elastic/oblt-aw.
- Prelude checks the Control Plane Dashboard.
- If enabled, the route runs the pinned agent from elastic/ai-github-actions.
See the architecture overview.
Here are some of the most important features of the oblt-aw framework:
- Automatic client distribution — no hand-copying entrypoints; distribution installs/updates
trigger-oblt-aw-*.yml(client template, adopting workflows). - Self-service dashboard — enable/disable with checkboxes on
[oblt-aw] Control Plane Dashboard(dashboard, opt-in / opt-out). - Shared prelude — same gating and allow lists before every agent run (aw-prelude).
- Shared agentic assets — resolved in the framework (aw-resolve-agentic-assets).
- Update once, reach the fleet — improve in
oblt-aw; distribution refreshes clients across active repos. - Quieter PRs — narrow triggers; only matching routes run (split-trigger).
- Catalog with maturity — registered workflows with clear maturity levels (workflows index, maturity).
- Clear ownership — shared core in one repo; per-org data under
config/<org-key>/(register a repo).
Not Observability-only. Each org owns config/<org-key>/; distribution and dashboard sync stay scoped to that org; consumers still get one shared dashboard grouped by org. Observability leads; docs already has a second org footprint. Details: multi-org design.
Target repositories install event-scoped client templates from this repository (for example trigger-oblt-aw-pull-request.yml, trigger-oblt-aw-issues.yml). Each event client calls an oblt-aw-event-* orchestrator that runs shared dashboard gating via aw-prelude.yml and passes shared-proceed (plus allow-list fields) into each route reusable.
- Observability templates: .github/remote-workflow-template/obs/.github/workflows/ — see docs/workflows/oblt-aw-client-template.md
- Docs templates: .github/remote-workflow-template/docs/.github/workflows/ (
trigger-docs-aw-issues.yml,trigger-docs-aw-issue-comment.yml,trigger-docs-aw-pull-request.yml,trigger-docs-aw-workflow-run.yml)
Executable workflows live under .github/workflows/; their docs live under docs/workflows/.
Primary repository documentation lives under docs/.
- Docs home: docs/README.md
- Architecture and design: docs/architecture/overview.md
- Workflow-specific docs: docs/workflows/README.md
- Routing docs: docs/routing/README.md
- Distribution and rollout operations: docs/operations/distribute-client-workflow.md
- Onboarding: docs/onboarding/README.md
- Guides by role: docs/guides/README.md
- Contributing and local setup: docs/development/contributing.md
Before opening a PR:
- Install pre-commit and run
pre-commit install - Run
pre-commit run --all-filesto validate locally - Run
pytest tests/andnpm testfor Python and TypeScript tests
See docs/development/contributing.md for full setup and check details.