Automating work is not enough
Most AI tools wait for you to turn messy work into a prompt. You gather the Slack thread, remember the meeting, find the issue, open the doc, explain what matters, and ask for help.
That is useful. It is also work before the automation starts.
Apprentice starts earlier: it learns from permissioned real work, then helps repeated work become reviewed automation.
Most work never becomes a workflow
Important work rarely lives in a clean process diagram.
It lives across Slack, GitHub, calendars, docs, browser tabs, customer messages, judgment calls, and half-finished context.
The work gets done, but the pattern disappears. Next time, the human reconstructs it from memory.
That is the gap Apprentice is built around.
The Apprentice loop
The first version is built around one practical loop.
Choose sources. Observe a bounded slice of real work. Prepare a proposal, draft, or next step.
Review the evidence. Correct what is wrong. Reuse what earns trust.
The point is not to make a user define an automation from scratch. The point is to let Apprentice watch the work, understand enough of the pattern, and ask for review before turning that pattern into something reusable.
The work itself is the interface. Review is how it becomes safe to reuse.
Review comes before autonomy
Apprentice should not make work louder. It should leave evidence, admit uncertainty, and learn from review.
For early users, the product is review-first: what Apprentice noticed, what changed, what it proposes, and what evidence supports that proposal.
The user should be able to approve, revise, reject, snooze, or correct it. Corrections are how the system learns what counts as useful work.
The trust boundary
Work context is sensitive, so the trust boundary has to be explicit.
Apprentice should work from permissioned sources. Users should know what is connected, what is observed, what can be paused or revoked, and what evidence supports each proposal.
We also need claims discipline. Demo data, fixture data, and internal tests are not live user proof. We will not present them as if they are.
What early users bring
Early users should bring one real workflow that keeps returning.
That might be a founder follow-up, research loop, engineering review, customer-ops response, recruiting thread, or project-coordination task.
We will measure trust and usefulness carefully: review burden, correction quality, proposal acceptance, repeated-work improvement, and earned autonomy over time.
We are not trying to prove a broad productivity claim from a polished demo. We are trying to learn which real work can become reusable, safely and measurably.
Bring one workflow you wish were easier. Apprentice will show evidence, learn from review, and improve over time.