Designing enterprise AI for repeatable consulting work with human-in-the-loop checkpoints.
I led the product strategy and design that moved Kenley from one-off AI interactions toward repeatable consulting workflows. I designed the editor, runtime, and output experience that enabled teams to create, run, monitor, and reuse structured work under enterprise constraints.
The central challenge was defining how autonomy, human judgment, observability, reuse, and client-ready outputs should work together as one product system.
What I led
- Defined the product model for reusable, AI-assisted consulting work.
- Designed the end-to-end experience across workflow authoring, discovery, execution, supervision, and output.
- Established the human-checkpoint model and led its delivery with engineering under role-based access control, GDPR, accessibility, and AI-reliability constraints.
Impact
- Workflows reached approximately 4,200 runs in a peak week, with 1,000–3,000 weekly runs typical at one enterprise tenant.
- Approximately 450 people used Workflows each week at that deployment.
- The deployment expanded more than 6x after launch.
- The wider product experience contributed to an approximately 95% reduction in deck-creation time and an 80% reduction in precedent-search time.
Why Workflows mattered
Kenley already helped consulting teams search institutional knowledge, synthesize evidence, and create deliverables through chat. Chat worked well for open-ended exploration, but it was a poor home for important work that followed a recurring sequence.
Research across multiple customer firms showed that most users stored certain prompts outside Kenley and copied them back into chat whenever they needed to repeat a task. The working method existed, but the product could not preserve its complete structure: which inputs mattered, which steps were required, where judgment was needed, or what the run was expected to produce.
Consulting work also rarely arrives as a clean template. Different firms use their own frameworks and methodologies, while individual projects combine procedural tasks, professional judgment, and AI-assisted reasoning.
The design challenge was to make that repeatable work visible, editable, and reusable without concealing consequential decisions inside an autonomous run.
Before Workflows
[Prompt stored elsewhere]
|
v
[Copied into chat]
|
v
[Opaque AI run]
|
v
[Deliverable rebuilt manually]
Context, review points, and decisions are lost between runs.
Product strategy
I separated workflow authoring from workflow execution while keeping both tied to the same underlying model: inputs, steps, sources, review points, and outputs.
Workflow authors needed an editor for defining the work’s logic, input files, runtime behavior, and intended result. Workflow runners needed a focused experience for starting the work, understanding its progress, and intervening when necessary.
The resulting system connected an organization-wide library, an editor, workflow launches from the library or chat, task-level activity, human checkpoints, and a path from completed runs to durable client deliverables.
Workflow lifecycle
**AUTHORING** **EXECUTION** **OUTCOME** [Author] -> [Publish] -> [Discover] -> [Run] -> [Review] -> [Resume] -> [Deliver]
1.Model the work, not merely the prompt
A saved prompt would have preserved instructions, but not the structure required to run a consequential task repeatedly.
I designed the editor to expose the workflow itself: its steps, input files, runtime settings, and output options. Authors could turn a recurring consulting method into an explicit sequence, while the organization-wide library made that sequence discoverable and reusable by other people.
The tradeoff was additional setup compared with saving a prompt. In return, important working logic moved out of private documents and old chat threads and into a product system that teams could inspect, maintain, and run repeatedly with high-quality compliant outputs.
2.Separate authoring from execution
The person defining a workflow and the person running it did not necessarily need the same interface.
Authors needed to reason about structure: steps, dependencies, source material, and output configuration. Runners needed to understand what the system required from them, what it was doing, and what would happen next.
I created distinct authoring and runtime experiences connected by the same workflow definition. This added another product mode to design and maintain, but prevented advanced configuration from overwhelming routine execution.
One model, two modes
AUTHORS RUNNERS
+----------------------+ +--------------------------+
| Define steps | | Provide run inputs |
| Bind sources | | Monitor activity |
| Set checkpoints | | Review checkpoints |
| Choose outputs | | Approve or correct |
+----------+-----------+ +------------+-------------+
| |
v v
+----------------------------------------------+
| SHARED WORKFLOW MODEL |
+----------------------------------------------+
3.Make autonomous work observable and interruptible
A multi-step AI system cannot be supervised through a start button alone.
Users needed to know what was running, what had completed, what required their input, what had failed, and what changed after an intervention. I designed activity and progress states that kept the run legible as it moved between tasks.
I also defined checkpoints that could pause a workflow after a set of tasks. At each checkpoint, the user could inspect the intermediate result, correct or approve it, and then allow the workflow to continue.
Checkpoints interrupted maximum automation and speed, but made consequential work reviewable before errors could compound. The system could move independently while the person remained accountable for the result.
Supervised runtime
[Run in progress]
|
v
[Checkpoint reached] ----> [Activity notification]
|
v
[Human review]
/ \
v v
[Correct] [Approve]
\ /
+----v----+
[Resume]
|
v
[Next task or output]
4.Treat the output as proof of success
A workflow is valuable because of what it produces, not simply because it completed.
After a run, its output could generate decks, spreadsheets, and Word documents automatically or on demand. These artifacts could be previewed and edited inside Kenley or exported to Microsoft 365.
Source citations carried through to the result so users could inspect the evidence behind the output before using it in client work.
Supporting durable artifacts and traceability was more demanding than returning plain text, but it closed the gap between AI reasoning and established consulting-delivery practices.
Adoption
At one life-sciences strategy consultancy, Workflows sustained 1,000–3,000 runs in a typical week and peaked at approximately 4,200, with around 450 weekly users. During the same period, paid seats expanded more than 6x.
Across the wider product, deck-creation time fell by approximately 95% and precedent-search time by 80%. These outcomes came from the deck-generation and retrieval experiences that Workflows connected into the delivery path.
Reflection
The checkpoint model changed how I think about autonomy in enterprise AI. The goal is not to keep a system running alone for as long as possible; it is to help people understand its plan, intervene at consequential moments, and stand behind the result.
In this context, human control was not a constraint on automation. It was what made automation dependable and trustworthy.
Customer Perspective
For another perspective on Kenley’s use in consulting practice, watch ClearView Healthcare Partners share their experience.