How Founder's Job Model Fits Ethen

Founder is Ethen's dedicated autonomous-jobs product: a separate application that carries work from a stated goal to a checked outcome, drawing on mission infrastructure and platform runtimes without absorbing them.

Most Ethen products answer a question or produce an artifact inside a session. Founder is shaped around a different unit of work: the job. A job starts with a goal, moves through planning, research, execution, approvals, and verification, and ends with a delivered outcome that can be reviewed. Understanding the Ethen Founder job architecture means understanding why that unit of work needs its own application, how a job moves through its lifecycle, and where Founder stops and shared infrastructure takes over.

This article explains Founder's product boundary, the operating-cycle states that govern a job, and its stated relationship to mission infrastructure and platform runtimes. It also states plainly what the inspected sources do not prove: end-to-end Founder-to-Missions integration and unattended autonomous operation remain unverified.

Why Founder is a separate app, not a Chat mode

Ethen's architecture direction is explicit on this point: Founder is not just a Chat persona. It is the autonomous-jobs product and should be its own dedicated Next.js application. The reasoning follows the ecosystem's central rule that one capability can appear on multiple surfaces but should have one canonical product owner and one shared backend and state.

Chat, by design, stays simple. Its canonical scope covers core conversation, a model selector, files, artifacts, tools, memory, and deliberately limited versions of deeper workflows: limited deep research, a curated Studio experience, lightweight design help, and lightweight coding. The architecture document states directly that Chat should not contain the full Computer product, the full Research workspace, the full Studio catalog, or the full autonomous Founder system. A job that plans, acts, requests approvals, and verifies outcomes needs persistence, review surfaces, and execution controls that do not belong inside a conversational thread.

The repository backs the separate-application claim at the package level. The Founder app exists as its own workspace package, @ethen/founder, with its own Next.js dependency, development server port, and build and typecheck scripts: an independent codebase entry point rather than a route or feature flag inside Chat. Plan reviews, approval grants, and evidence inspection then happen in Founder's own surfaces, with their own history, instead of competing with chat transcripts.

What the Founder app owns

The architecture direction gives Founder a concrete product scope. Its surfaces are organized around the lifecycle of jobs:

• New Job and Jobs for stating goals and tracking each unit of work.
• Runs, Plans, and Tasks for breaking a goal into steps and following execution.
• Evidence and Results for recording what happened and what was delivered.
• Approvals for gating consequential actions behind human decisions.
• Files, Connections, Spend, and Activity for the working context, integrations, cost visibility, and audit trail around a job.

This scope is what makes Founder a product rather than a prompt. A job is a durable object with a plan, a spend record, an approval history, and attached evidence — not a single model response. Approvals and Evidence as first-class surfaces show the design assumes autonomous execution still passes through checkpoints a person can inspect, and that completion means something checkable rather than merely asserted. The marketing index describes the Founder product page modestly, as a product for thinking through company-building work — consistent with what the sources establish: the product's intended shape and code boundary, not a shipped service.

The job lifecycle, as code

The most concrete implementation evidence for Founder's job model is its operating-cycle state machine. The orchestrator module defines a durable cycle with a pure transition table and guards: the orchestrator and worker may only move cycles through the transitions declared in that table, and anything else is treated as a defect.

The cycle states cover the full shape of a job's life:

• draft — a job that has been sketched but not yet queued.
• queued — a job waiting for execution capacity.
• paused — a job deliberately held before or between runs.
• running — a job currently executing.
• retrying — a transitional state while a failed or interrupted attempt is being retried.
• cancel_requested — a cancellation that has been asked for but not yet completed.
• succeeded, failed, cancelled — terminal outcomes.
• timed_out, dead_lettered, dependency_failed — failure-holding states that record why a job stopped.

The allowed transitions read like a specification for careful operations. A draft can move to queued or be marked failed. A queued job can start running, be paused, be cancelled, or land in one of the failure-holding states. A running job can succeed, fail, request cancellation, time out, or be dead-lettered. A paused job can resume to queued or be cancelled. A cancellation request resolves only to cancelled.

Two properties of this table deserve attention. First, retries never duplicate logical jobs. The module's own documentation states that operator retries re-queue the same logical cycle, and that retries create attempts rather than duplicate jobs. That is the difference between a system that can be safely retried and one that silently multiplies work: re-running a timed-out job continues the same job's history instead of spawning a lookalike.

Second, the failure-holding states are recoverable only through explicit operator action. A failed, timed-out, dead-lettered, or dependency-failed cycle can return to queued — but that path represents a deliberate retry operation, not an automatic loop. The strict transition helpers enforce this: one function checks whether a transition is legal, and another throws on anything illegal. Together they turn the lifecycle diagram into something the code refuses to violate.

Consider a job asked to research three suppliers and draft a comparison. It starts as a draft while the goal is stated, moves to queued on submission, and enters running when execution begins. If a dependency — a credential or an upstream fetch — is unavailable, the cycle lands in dependency_failed rather than pretending to proceed; an operator fixes the dependency and re-queues the same logical job as a new attempt under the same identity. If the user changes their mind mid-run, the job moves through cancel_requested to cancelled, which is final: no transition leaves cancelled or succeeded.

This is a meaningful slice of implementation. It shows that Founder's job model is not only a product narrative but also a guarded state machine with named failure modes and explicit retry semantics. What it does not show, on its own, is the rest of the execution path: the planner, the tool calls, the browser or computer runtime, and the verification step all sit outside this one module.

From goal to verified outcome

The architecture direction describes Founder's purpose in one line: give Ethen a job and let it carry the work from goal to verified outcome. The intended execution model expands that line into a sequence:

Goal, to creating the job, to planning, to research, to execution — using tools, the browser or computer runtime, and code — to requesting approvals, to verification, and finally to delivering the outcome.

Each stage earns its place. Planning turns a goal into steps before anything irreversible happens. Research gathers the information those steps need. Execution uses tools and runtimes rather than text alone, which is what separates a job from an answer. Approvals insert human decisions before consequential actions. Verification checks the result against the goal. Delivery closes the loop with something the user can review.

In the supplier-comparison example, planning decomposes the request into finding candidates, gathering comparable facts, and drafting; research collects sourced facts; execution assembles the draft; an approval checkpoint gates sharing it outside the team; verification checks each claimed fact against gathered evidence; delivery presents the comparison with that evidence. No stage is optional by default: a Founder job is expected to show its working, not just its conclusion.

This execution model is a documented design target. It describes what Founder is for, not what has been demonstrated running end to end — the contract to judge future Founder releases against, stage by stage.

Founder and mission infrastructure

The most architecturally interesting relationship in this article is between Founder and Ethen's mission infrastructure. The architecture direction says Founder can use the Missions architecture underneath, naming its concepts: Mission Contract, Constraint Ledger, Authority Envelope, Execution, Verification, Evidence, and Recovery. But it adds an equally important sentence: the customer-facing product remains Founder.

That framing establishes a clean layering. Missions infrastructure provides the durable machinery for constrained, verifiable agent work — contracts that state what is allowed, ledgers that record constraints, envelopes that bound authority, execution engines, verification passes, evidence stores, and recovery paths. Founder provides the product surface where a person states a goal, watches plans and runs, grants approvals, and receives results. If the layering holds, Founder jobs gain durability and verifiability from underneath while users interact with jobs, not infrastructure primitives.

The word "can" carries real weight here and must not be upgraded silently into "does." The inspected sources — the architecture direction, the Founder package manifest, and the operating-cycle state machine — do not demonstrate a complete, wired-up Founder-to-Missions integration. The Founder cycle states describe Founder's own operating lifecycle; the mission concepts belong to a separate infrastructure layer whose connection to Founder is stated as intent, not shown as implementation. Until integration evidence exists — shared types, called interfaces, or tests exercising the handoff — the honest statement is that Founder is designed to build on mission infrastructure, and that the completeness of that integration is unproven.

This distinction matters for how readers evaluate autonomy claims. A guarded operating cycle plus a mission layer with verification and recovery would be a strong foundation for jobs that survive failures and prove their outcomes. Either layer alone is only part of the story. The architecture aims at both; the evidence so far shows the Founder-side lifecycle in code and the mission relationship as direction.

Founder and the platform runtimes

Founder's relationship to Platform follows the same pattern: use the runtime, don't duplicate the management surface. Three Platform capabilities are most relevant.

First, Auto and Cortex form the orchestration and autonomous-execution control layer, with agents, runs, plans, tools, approvals, policies, budgets, execution, verification, and observability. The architecture direction says Founder may use Auto and Cortex internally, while Platform gives advanced users the full operating surface. In other words, Founder jobs might execute through the same orchestration machinery that Platform exposes directly — but a Founder user would see jobs and approvals, not the full control plane.

Second, Computer is Platform-only as a management surface, while other products may use its runtime behind the scenes. The architecture document gives the exact example: a Founder job flows into the Computer runtime, which performs a website action — while sessions, screens, permissions, takeover, and credentials stay managed in Platform. Founder needs the ability to request supervised actions through that runtime, not its own browser farm.

Third, Automation belongs in Platform for configuration and management, while Founder and Auto can create or invoke automations. A Founder job might trigger a repeatable workflow without owning the workflow's triggers, schedules, secrets, or retry policies.

The ownership matrix summarizes the pattern: Founder's canonical home is the Founder app, with links from Chat and Platform; Auto and Cortex are used by the Founder runtime; Computer is a runtime capability for Founder and Auto; Automation can be invoked by them. Each row keeps management in one place and consumption in another. As with missions, these rows describe intended relationships. They establish where things belong when built — they are not, by themselves, proof that every connection is live.

Entry points without duplication

If Founder is separate, how do users find it? Through links, not copies. The architecture direction places Founder in the Platform launcher's app list as an external link alongside Chat, Research, Studio, and Designer, and the ownership matrix notes links into Founder from both Chat and Platform. A Chat user with a request too durable for conversation can be handed off to Founder; a Platform operator can jump from orchestration views into the job surface. Chat stays fast because it hands jobs off, Platform stays a control plane because it links rather than re-implements, and the job itself lives in one place.

What is proven and what is not

Product writing about autonomous systems carries a specific obligation: separate what exists from what is merely planned. For Founder, the inspected sources support three claims and leave two important ones open.

Proven, within the scope of the sources: first, the standalone application boundary exists in source form — the @ethen/founder package with its own Next.js setup is real and inspectable. Second, the operating-cycle state machine exists as code, with named states, a strict transition table, and documented retry semantics. Third, the architecture direction exists as an explicit authority document, and it is detailed about Founder's scope, execution model, and intended relationships to missions, orchestration, computer runtime, and automation.

Not proven: first, complete Founder-to-Missions integration. The design says Founder can use mission concepts underneath, but none of the inspected sources show the wiring — no shared contracts exercised, no handoff tested, no evidence that a Founder cycle and a mission record move together. Second, unattended autonomous operation. A state machine with pause, cancel, timeout, and dead-letter handling is a prerequisite for trustworthy long-running work, but states alone do not demonstrate a job running to completion without supervision, recovering from real failures, or verifying its own outcome against its goal. No benchmark, deployment record, or launch evidence was among the inspected sources, and this article makes no availability claim: Founder's launch status is a separate gated question, not something this product explainer can settle.

Readers evaluating future Founder announcements should ask for exactly the evidence named here: a job record showing attempts under one logical identity, an approval checkpoint gating a real action, verification output tied to evidence, and a recovery path exercised after a genuine failure. The architecture tells us what to look for. Only running evidence can show it is there.

The shape of the answer

Founder fits Ethen as the jobs product: its own application, its own lifecycle, its own review surfaces — built to draw on mission infrastructure and platform runtimes while leaving each of them under its canonical owner. The guarded operating cycle shows the job model taking form in code. The mission and runtime relationships show where it is headed. What remains is the hardest part of any autonomous system: proving, with evidence rather than narrative, that jobs complete, verify, and recover as designed.