About
Enablement Engineering builds applied AI adoption systems for workflows generic tools cannot handle.
Eval loops. Agent tools. Accessibility-aware content pipelines. Review processes that need evidence.
Led by Dylan Isaac, the practice combines accessibility, agentic systems, production engineering, and technical enablement.
What Enablement Engineering builds
Our work includes Equalify Reflow with UIC Digital Accessibility Services: a production AI pipeline that transforms inaccessible academic PDFs into semantic, accessibility-first web content. This work was presented at CSUN 2026.
We also build open-source infrastructure such as Gobbler, a toolchain for converting authorized videos, documents, web pages, audio, and browser sessions into agent-ready context.
The common thread is reviewable AI adoption: real materials, explicit procedures, evaluation criteria, human review gates, and handoff artifacts the team can keep using after launch.
View Enablement Engineering on GitHub (opens in a new tab) or view Dylan on GitHub (opens in a new tab).
Before Enablement Engineering
Before founding Enablement Engineering, Dylan was Lead AI Engineer at Deque, where he worked on axe Assistant and production approaches to AI-assisted accessibility workflows.
That background shaped the practice. Accessibility AI fails in specific ways: semantics get flattened, evidence disappears, mistakes hide inside confident output, and review teams need more than a good demo. Enablement Engineering was built around those lessons.
What this maps to
In hiring and partnership language, this work sits at the intersection of applied AI engineering, AI deployment, technical enablement, and responsible adoption. The through-line is turning expert practice into systems people can inspect, operate, teach, and improve.
Workflow implementation
Real materials, stakeholder constraints, prototypes, integrations, and deployment paths shaped around how the work actually runs.
AI deployment
Evaluation harnesses, acceptance criteria, review gates, observability, and operational handoff.
Technical enablement
Demos, labs, documentation, use-case libraries, training, and field-ready explanation.
Public-good AI
Accessibility, education, governance, and systems where trust has to be documented.
Working principles
Ladders, not walls.
Systems should increase the team's capability, not create a black box only the vendor can operate.
Mirrors, not slot machines.
AI should reflect the team's standards, constraints, and review process, not optimize for novelty or plausible output.
Visible enough to challenge.
Reasoning, tool use, review points, and failure states should be visible enough for humans to inspect and correct.
How we engage
We usually start with paid discovery: a short working engagement against real content, a real workflow, and a real artifact. That gives both sides enough evidence to scope a build responsibly.
The goal is not to make clients dependent on us. The goal is to leave behind systems, procedures, evaluation criteria, and documentation that teams can understand, inspect, and improve.