---
slug: "workflow-elicitation"
name: "Workflow Elicitation"
packType: "harness"
canonicalPattern: "hybrid"
version: "0.1.0"
trust: "Community"
publisher: "Open Workflow Lab"
updatedAt: "2026-04-15"
---

# Workflow Elicitation

> Capture operator judgment before you automate it.

## Summary

A future-facing pattern for teams that need to externalize tacit expertise into reusable operating instructions before they try to scale an agent across a domain.

## Install

```sh
npx attrition-sh pack install workflow-elicitation
```

### Claude Code / AGENTS.md snippet

```md
# Workflow Elicitation
# See: /packs/workflow-elicitation

```

## Contract

_No execution contract defined for this pack type._

## Layers

_No three-layer split defined for this pack type._

## Use When

- The team has experienced operators whose judgment is hard to explain.
- Prompts keep getting longer because the real operating system is still implicit.
- You need a reusable role charter, escalation rules, and preferred answer shape.

## Avoid When

- The workflow is already explicit and encoded in deterministic rules.
- You only need a lightweight prototype with minimal domain nuance.

## Key Outcomes

- Tacit knowledge is converted into reusable instructions and decision boundaries.
- The runtime gets better because the operating system is clearer.
- Model choice becomes less important than task specification quality.

## Minimal Instructions

Do not start with the assistant.

Start with an elicitation pass that captures:
- the role charter
- recurring decisions
- escalation boundaries
- trusted sources
- preferred response structure

Treat that operating system as an input to the runtime harness.

## Full Instructions

When the workflow depends on expert judgment, add an elicitation stage before building the main assistant.

The elicitation stage should capture:
- what the operator is trying to optimize for
- what facts must be cited
- what decisions can be taken autonomously
- what requires escalation
- what sources outrank others
- what a successful answer looks like

Persist those outputs in a structured operating-system layer. Then feed that layer into the runtime harness, evaluation rubric, and role-specific UI.

## Evaluation Checklist

- Can the operating system be read without talking to the original expert?
- Are escalation rules and trusted sources explicit?
- Do runtime instructions reference this operating system instead of ad hoc prompt additions?

## Failure Modes

- **[MID] The team keeps patching prompts instead of capturing the missing workflow rules.**
  - Trigger: (legacy — trigger not separated)
  - Prevention: (legacy — no explicit prevention)
- **[MID] Expert operators agree on outcomes but disagree on undocumented intermediate judgment.**
  - Trigger: (legacy — trigger not separated)
  - Prevention: (legacy — no explicit prevention)
- **[MID] The operating system is freeform notes with no reusable structure.**
  - Trigger: (legacy — trigger not separated)
  - Prevention: (legacy — no explicit prevention)

## Transfer Matrix

_No measured cross-model transfer data._

## Telemetry

_No telemetry recorded._

## Security Review

_No security review on file._

## Compares With

_No comparative data._

## Related Packs

_No related packs._

## Changelog

_No changelog entries._

## Sources

- [OpenClaw ecosystem notes](https://docs.openclaw.ai/index) — Useful context for structured agent instructions and operating patterns.
- [Agent Workspace README](https://github.com/HomenShum/agent-workspace-template) — Shows how a reusable platform can sit underneath multiple domain implementations.

## Examples

- [Template repo](https://github.com/HomenShum/agent-workspace-template) (external)