What Ethen Work Is Meant to Become

Ethen Work is our working name for the experience we are designing for delegated work: tasks that take minutes, hours or days, cross several tools, and should come back finished and checkable rather than as a long chat transcript. The idea is simple to state. You describe the outcome you want and what "done" means. You set boundaries — what the work may touch, what it may spend, and which steps need your approval. Ethen plans and carries out the work in the background, asks you only at the decisions that matter, and returns a result together with evidence of what was done, what was checked and what is still unknown. Ethen Work is direction, not a launched product, and it may ship under a different name or as part of existing Ethen apps.

Key takeaways

• Delegation needs a different container than conversation. A piece of work needs a goal, boundaries, a plan, decisions and a result with evidence.
• Done is defined first. The most important field in a work item is how anyone will know it is finished.
• Boundaries come before autonomy. Scope, budget and approval points are set before work starts and enforced while it runs.
• Interruptions should be rare and useful. The work asks for a person when a decision genuinely needs one, with enough context to answer quickly.
• It builds on foundations that already exist. Durable jobs, evidence-gated completion, honest unknowns and bound approvals are implemented mechanisms in Ethen's platform.

What is Ethen Work?

Ethen Work is the direction for a general-purpose place to hand off work to Ethen and get it back done. "Work" here means a one-off piece of work with an outcome — prepare a vendor comparison, reconcile last month's invoices against purchase orders, clean up a shared drive, compile a briefing from twenty documents, chase down the cause of a recurring support issue. It sits between two things Ethen already does well. Ethen Chat is for asking: a question, a draft, a quick analysis that fits in a conversation. Ethen Automation is for repeating: a defined process that runs on a schedule or an event. Delegated work is neither. It happens once, it has a goal rather than a script, and it usually needs some judgment along the way.

We are being careful with the name because it is not settled. This article describes what we want delegated work to feel like in Ethen and the principles behind it. It does not announce a product, a release date or a price.

Why doesn't delegated work fit in a chat?

Chat is built for turn-taking: you say something, the model responds, and you judge the response on the spot. Delegated work breaks every part of that loop. It runs while you do something else. It involves steps you will not watch. It may need your input at an unpredictable moment, hours after you started it. And when it ends, the important question is not "was that a good reply?" but "did the work actually get done, and how do I know?".

When delegated work is squeezed into a chat thread, three things go wrong. The definition of done is never written down, so the agent decides for itself when it is finished. The boundaries live in a sentence early in the conversation — "don't email anyone without asking me" — that is easy for a long-running process to lose. And the result arrives as a confident summary, with the evidence scattered across tool calls nobody reviews. We explore the general case in Why Long-Running AI Work Needs a Different UX Than Chat.

What should a piece of delegated work hold?

A piece of delegated work should hold everything needed to start it, supervise it, pause it, resume it and check it — in one place.

Goal and definition of done. What outcome is wanted, and how will anyone know it was reached? "Compare three vendors" is a goal. "A table of three vendors with pricing, contract terms and support levels, each cell linked to its source document" is a definition of done. The second version can be checked.

Boundaries. Which tools, accounts and data the work may use; what it may spend; and which kinds of action need a person's approval first. Boundaries are set before the work starts and enforced while it runs, not left as instructions the agent is trusted to remember.

Plan and progress. The steps the work intends to take, what has happened so far, and what comes next. A plan is useful mainly because a person can glance at it and catch a misunderstanding early.

Decisions. Questions that genuinely need a person: an approval for a consequential action, a choice between two reasonable interpretations, a missing piece of information. Each should arrive with the context needed to answer it in under a minute.

Result and evidence. What was delivered; what was checked and how; and what remains unknown or unfinished. A result without evidence is a claim.

How does Ethen Work relate to other Ethen apps?

Ethen Work is meant to be the general home for one-off delegated work, alongside apps that own more specific kinds of work.

• Ethen Chat remains the place to ask, draft and explore. When a conversation turns into "can you go and do this?", Chat should hand the request to a work item rather than try to run it inside the thread.
• Ethen Automation owns repeatable workflows with triggers, schedules and run history. If a delegated task turns out to be something you need every week, it should become an automation.
• Ethen Founder is Ethen's app for company-building jobs carried from a goal to a verified outcome, with jobs, runs, plans, approvals, evidence and spend as first-class surfaces. Its job model is described in How Founder's Job Model Fits Ethen.
• Ethen Code owns software tasks, where the evidence is tests, builds and review.

These boundaries follow Ethen's general product rule: one capability, one canonical owner, shared foundations underneath.

The principles behind delegated work

Seven principles shape what we are designing. They are commitments about direction, not descriptions of shipped behavior.

1. Done is defined before work starts

The work item asks for a definition of done up front and proposes one when the person has not given it. That single field changes everything downstream: what the plan aims at, what the checks look for, and what the result is judged against. Why "done" deserves this much attention is the subject of What "Done" Should Mean for an AI Agent.

2. Boundaries come before autonomy

Ethen should never gain authority by accident. Scope, budget and approval points are part of the work item, visible to the person who set them, and checked before consequential steps. Ethen Research Lab's research note Mandates proposes compiling a person's intent into exactly this kind of bounded authority; it is an architecture proposal that has not been implemented or tested as described, and we cite it for the principle.

3. Ask only when it matters

A delegated task that asks for permission every few minutes is not delegation. One that never asks is not safe. The design goal is to interrupt for consequential actions, genuine ambiguity and missing information — and to batch or defer everything else. Human-AI interaction research has long recommended timing interventions to the user's context and making it easy to dismiss or correct an AI system's actions (Amershi et al., 2019). We discuss where approvals belong in Why Ethen Keeps Human Approval in the Loop.

4. Evidence over narration

The result of a work item is not the agent's summary of what it did. It is the delivered output plus the evidence behind it: sources linked to claims, records of actions taken, checks run, and their outcomes. The summary is still useful — it is how a person orients — but it is not the proof.

5. Unknowns are reported, not hidden

Sometimes the work cannot establish what happened: a message may or may not have sent, a record may or may not have updated. Those outcomes should be reported as unknown, with what was done to find out, rather than rounded to success or failure. Ethen's mission system already treats unknown outcomes this way, as described in When an Agent Action's Outcome Is Unknown.

6. Work survives interruptions

Delegated work will be interrupted: by a network failure, a provider outage, a restart, or a person who needs to think overnight before approving something. A work item should pause cleanly and resume from where it was, without repeating actions that already happened.

7. You can always take over

A person should be able to stop the work, change the plan, do a step themselves, or take the whole thing back at any point — and the record should show who did what.

What does it build on?

Ethen Work is direction, but the foundations it needs are implemented mechanisms in Ethen's platform, each described with its stated test limits.

• Durable jobs. Ethen's job service ensures that only one worker acts on a job at a time, that a stale worker cannot overwrite newer progress, and that uncertain outcomes are reconciled from evidence rather than retried by default. See Inside Ethen's Durable Job Service.
• Evidence before completion. In Ethen's mission system, the component that does a task cannot mark it successful on its own; completion requires independent evidence. See Making Mission Completion Depend on Evidence.
• Honest unknowns. Outcomes that cannot be confirmed stay open until evidence resolves them.
• Approvals bound to actions. In the computer-use path, each approval covers one specific action under a named policy and cannot be reused for something else.

Building delegated work on these foundations, rather than on a chat loop, is what makes the principles above enforceable instead of aspirational.

An illustrative example

Illustrative example — a hypothetical work item, not a description of shipped behavior.

A team lead hands Ethen a piece of work: "Prepare our quarterly vendor review." Ethen proposes a definition of done — a summary of spend by vendor for the quarter, contract renewal dates in the next six months, and three vendors flagged for renegotiation with reasons, every figure linked to its source. The lead adjusts it and sets boundaries: read access to the finance system and the shared contracts folder, no outbound email, a spending cap for any paid data lookups.

Work runs in the background. Partway through, Ethen finds two contracts with conflicting renewal dates and asks which document is authoritative, showing both. The lead answers on their phone. When the work finishes, the result is the table, a short summary, links from every number to its source, a list of the three files Ethen could not open, and a note that one vendor's spend could not be reconciled because two invoices had the same number. Nothing was sent to anyone. Nothing was paid. The open questions are visible rather than buried.

What we are not claiming

Ethen Work is a working name for a direction. We are not announcing a product, a release date, availability, pricing or performance. Some of the capabilities described here may arrive inside existing apps rather than as a separate one. The foundations listed above are implemented mechanisms with stated limits; the experience built on them is still being designed.

Tradeoffs

Defining done and setting boundaries takes effort up front, and some people will prefer to "just ask". The product has to make good defaults easy — proposing a definition of done and sensible boundaries — without turning every request into a form. Fewer interruptions mean more trust placed in the boundaries, which is why the boundaries have to be enforced by the system rather than remembered by the model. And background work changes when people notice problems; a work item has to be easy to check at a glance, or delegation simply moves the work of supervision somewhere less visible.

Frequently asked questions

Is Ethen Work available? No. Ethen Work is a working name for the delegated-work experience we are designing. This article describes direction.

How is Ethen Work different from Ethen Founder? Founder is Ethen's app for company-building jobs carried from a goal to a verified outcome. Ethen Work is the direction for general one-off delegated work. They share the same foundations.

Will Ethen Work act without asking me? Within the boundaries you set, routine steps can proceed without interruption. Consequential steps — such as sending messages, spending money or changing records outside the agreed scope — are designed to require your approval.

What happens if something fails halfway? The work should pause, report what is known and unknown, and resume without repeating actions that already happened. We describe this in What Happens When an AI Task Fails Halfway Through?.

Related Ethen research

• Mandates: Compiling Human Intent Into Bounded Agent Authority — bounded authority (architecture proposal; not implemented as described).
• Commitment Graphs: Why AI Agents Need to Know What Is Still Unfinished — tracking what is still owed (research proposal; untested).

Related topics

• AI Agents and Autonomous Work — Ethen's hub for long-running agent work.
• Designing Ethen for Work That Takes Minutes or Hours

References

1. Amershi, S. et al. (2019). Guidelines for Human-AI Interaction. Proceedings of CHI 2019. https://www.microsoft.com/en-us/research/publication/guidelines-for-human-ai-interaction/
2. Ethen Blog (2026). How Founder's Job Model Fits Ethen. https://upcube.ai/blog/how-founders-job-model-fits-ethen
3. Ethen Blog (2026). Inside Ethen's Durable Job Service. https://upcube.ai/blog/inside-ethens-durable-job-service
4. Ethen Blog (2026). Making Mission Completion Depend on Evidence. https://upcube.ai/blog/making-mission-completion-depend-on-evidence
5. Ethen Blog (2026). When an Agent Action's Outcome Is Unknown. https://upcube.ai/blog/when-an-agent-actions-outcome-is-unknown
6. Ethen Research Lab (2026). Mandates: Compiling Human Intent Into Bounded Agent Authority. Research note; architecture proposal. https://upcube.ai/resources/research/agent-mandates
7. Ethen Research Lab (2026). Commitment Graphs. Research proposal; untested. https://upcube.ai/resources/research/commitment-graphs