Ethen topic
An AI agent is software that uses a model to plan and take actions toward a goal, often over many steps and against external systems. Autonomous work is the part that matters operationally: the agent acts rather than only answers, so its effects persist after the conversation ends.
Because agent work unfolds over time, the engineering problems are different from chat. Jobs must survive worker crashes, a person must be able to intervene at defined points, an action whose outcome is unknown must not be retried blindly, and completion should be proven rather than declared.
Ethen builds agent work as durable jobs with approval points and evidence-gated completion. The articles below describe those mechanisms as they exist in Ethen's code, including their stated limits. The Ethen Research Lab publications describe open research directions. Most of them are proposals and research syntheses, not measured results.
A chat answer can be judged on the spot. An agent job plans, acts on external systems, gets interrupted, retries, and can leave effects nobody has confirmed. If the agent's own summary is the only record of success, you have a story, not a result. That is why verifiability has to be designed in.
Ethen's durable job service is built to survive worker crashes, using fenced leases, execution envelopes, dispatch boundaries, and evidence-driven reconciliation. Automation triggers are kept separate from execution: an event is bound to its subscription, redeliveries are deduplicated, and runs are enqueued rather than executed inline.
It should not guess. A timeout is not permission to retry. Ethen's mission reconciler retains the uncertain effect and resolves it only with evidence. The Research Lab note on unknown effects describes the general pattern: reconcile before retry, idempotency keys, and compensation.
At approval points. Ethen binds each computer-use approval to the exact action, run, and attempt it covers, so an approval cannot be reused for a different action. A Research Lab note proposes the mandate as a broader direction: one object that compiles human intent into budgets, approvals, delegation limits, expiry, and revocation. The mandate is a proposal and has not been tested.
An agent job is verifiable when someone other than the agent can confirm what was supposed to happen, what actually happened, and what remains unknown. This guide turns that idea into a checklist you can apply to any system.
An agent action is interrupted mid-flight: did it happen? Ethen's mission reconciler refuses to guess — it retains the effect as unknown until evidence resolves it.
Leases decide who may act, envelopes decide who the work belongs to, and reconciliation decides what actually happened.
Ethen's trigger boundary accepts an event only if it matches its subscription, records it once, and hands execution to someone else.
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.
In the Stage-0 mission system, running the work and proving the work are different transitions — and only independent evidence unlocks the second.
These publications are research syntheses, proposals, and benchmark designs. None reports new measured Ethen results. Each page states its evidence status.
A research note on idempotency for AI agents: unknown effects after timeouts, reconcile-before-retry, idempotency keys, compensation and exactly-once limits.
A research proposal for commitment graphs: tracking intent, obligations, preconditions, effects and evidence so AI agents stop declaring unfinished work complete.
A research proposal on AI agent error recovery: branch each failure in a sandbox into candidate recoveries and learn when to retry, reconcile, escalate or stop.
A research note on mandates: one object that compiles human intent into AI agent authorization, budgets, approvals, delegation limits, expiry and revocation.
A research paper proposing a multi-axis AI agent failure taxonomy, the failure genome, built on recent work on failure modes, attribution and critical steps.
Upcube's September 20 architecture map gives every Ethen capability one canonical home — and leaves several migrations visibly unfinished.
Chat is Ethen's fast front door, not the whole building. Here is what belongs inside it — and where everything else lives.
Ethen is organized as a family of focused apps rather than one universal chat window because different kinds of AI work need different things to persist, different controls, and different evidence. A quick question needs a thread. A research investigation needs sources and branches that survive across sessions. A code change needs a repository, tests and review. A goal-driven job needs a plan, approvals and a record of what actually happened. Ethen gives each kind of work one canonical home — Chat, Code, Studio, Research, Designer, Founder, the Platform products and Desktop — and keeps the account, model access, permissions and evidence shared underneath, so it still works as one Ethen.
As of October 2026, Ethen's work falls into five areas. We are organizing Ethen into focused apps that share one foundation. We are hardening that foundation for AI work that runs for minutes or hours: durable jobs, completion that depends on evidence, honest handling of unknown outcomes, and approvals tied to specific actions. We are building a model knowledge layer so people can choose models with sources rather than guesses. We are extending Ethen to local, on-device AI through Desktop. And Ethen Research Lab now publishes its research in public, with every paper labeled by evidence status. This update separates what our public posts describe as implemented from what is design direction, and it makes no launch or date commitments.
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.
The next phase of Ethen Chat is about doing the same job better, not about doing more jobs. Chat stays Ethen's fast, general conversational front door, deliberately limited in scope. What changes is how well it carries context. We are working toward six improvements: continuity across sessions and devices that you can see and control; hand-offs that bring your context along when work outgrows a conversation; quick research answers whose sources you can check; voice as a natural way into the same conversation; model choice that explains itself; and honest signals about what Chat does not know. This article explains each direction, what already exists, and what we are not claiming. It contains no release dates.
Reliability for AI products means more than staying up. For AI work that acts — editing files, sending messages, generating paid media, running for hours — a reliable system must do four things: be available, make sure each real-world effect happens once rather than twice, make sure tasks actually succeed rather than merely report success, and tell people the truth about what is pending, failed or unknown. Ethen's reliability program works on all four layers. Its main parts are safe retries that never duplicate effects, durable jobs that survive crashes and resume cleanly, deliberate fault testing, verification that is budgeted before work begins, release evidence that states exactly what was checked, careful handling of model and provider changes, and honest status everywhere. This article describes that program at a high level and links to the engineering posts behind each part.
An AI workspace is a persistent place where people and AI systems work on something together. It holds six things a conversation does not: the context the work depends on, the artifacts being made, the state of the work (done, pending, blocked, unknown), the tools and permissions the AI may use, the people who own and review the work, and the history and evidence of what happened. A chat window can be one way to interact with a workspace, but it is not the workspace itself. The practical test is simple: if you closed the conversation, would the work still be there, organized, and checkable? If not, you were using a chat, not a workspace.
Long-running AI work needs a different user experience than chat because chat is built on four assumptions that stop being true once work lasts longer than a few minutes: that the work takes seconds, that you are watching, that the result is a single reply, and that you can judge that reply on the spot. AI agents that research, code, operate tools or carry out multi-step tasks now routinely run for minutes or hours, often while the person who started them does something else. That work needs a job with its own identity and state, progress shown as phases rather than a spinner, decision points that reach you at the right moment with the context to answer, pause, resume and recovery that never repeat an action twice, and a result delivered with evidence for review — not a confident final message.
Ethen designs background AI tasks so that their status and progress stay clear however long they run. It does that by matching the experience to how long the work takes, and by making the job — not the conversation — the thing people watch, leave and come back to. In practice that means five design commitments. Work is presented by duration tier: seconds stay in Chat, minutes become a visible job, hours run in the background with a timeline, and days become delegated work with checkpoints. Status uses a small, honest vocabulary that simplifies what the system tracks without ever rounding an unknown outcome into success or failure. Costs are shown before work runs where they can be known. Interruptions are reserved for decisions that genuinely need a person. And every long job resumes safely and ends in a review with evidence. These commitments rest on foundations described in our engineering posts; the experience built on them is still evolving.
Ethen is building for recoverable AI work because failure is a normal part of long-running work, and what happens after a failure decides whether it becomes a brief pause or an incident. Recoverable AI work means that after any interruption — a crash, a timeout, a provider outage, a revoked permission, a person who needs to think — the work is in a known state, and the next move is a deliberate choice: continue from the last good point, reconcile an uncertain outcome, undo a partial effect where a real undo exists, escalate to a person, or stop safely with an accurate account of what happened. Five foundations make that possible: durable state, actions tied to their intent so repeats do not repeat effects, reconciling before retrying, compensation used only where it is meaningful, and clean stopping and hand-over.
When an AI task fails halfway through, what happens next depends on one question: did anything change in the world before it failed? A well-designed system handles that question in a fixed order. It stops making new changes. It works out what finished, what did not, and what is uncertain. It checks the uncertain steps by asking the system of record what actually happened. Then it chooses the next move — resume from the last good point, retry only where that is safe, finish just the remaining items, undo a partial change where a real undo exists, or stop and ask you — and it tells you only when a decision genuinely needs you. What it should never do is guess, start over from the beginning, or report the task as either finished or failed when it does not know which.
Ethen Founder is built around a simple idea: founders do not need another place to talk to AI; they need work carried through to a result they can check. So Founder's unit of work is the job, not the conversation. You state a goal and its limits. Founder plans the steps, does the research and the work, stops for your approval before anything consequential, checks the result against the goal, and hands back an outcome with its evidence, spend and history attached. That design makes Founder a separate app from Ethen Chat rather than a chat mode. It also comes with explicit limits on what Founder may do on your behalf. This article explains the thinking, what is published about Founder's design, and what has not yet been proven.
Delegating work to AI is different from asking AI in one fundamental way: when you ask, you do the work with the answer; when you delegate, the AI does the work — but you are still accountable for the result. That shift changes almost everything else. A question becomes a brief with a goal, limits and a definition of done. Checking happens at checkpoints and at the end, not once when you read a reply. The AI needs authority to act, and that authority needs boundaries. And what comes back is an outcome with evidence, including an honest account of anything unfinished or uncertain. This guide explains each change, offers a five-part delegation brief you can use with any agent, and describes when not to delegate at all.
AI for small teams has to work under constraints large companies rarely face: no IT department to set it up, no spare time to check every result, budgets that cannot absorb surprise bills, customer data that still needs protecting, and headcount that changes every few months. Those constraints shape how we design Ethen for founders and small teams. The aim is AI that finishes bounded pieces of work with results that are quick to review, shares context across a few people without administrative overhead, keeps spending visible and limited, protects data by default, and grows from one founder to a team without forcing a move to a different system. This article explains those principles, where AI helps small teams most today, and where we think care is still needed.
An AI-native company is one that uses AI agents throughout its own work — engineering, research, writing, analysis and operations — rather than only selling AI to others. Ethen is built that way. But using agents everywhere is the easy part. The hard part is keeping the company honest while it does: making sure people stay accountable for every decision, agents work within bounded authority, the context they rely on is written down where both people and agents can read it, claims carry evidence rather than confidence, output and spend are measured rather than assumed, and the judgment that decides what is right is hired for, practiced and protected. Those six principles are the same ones we design into Ethen's products, applied to ourselves. This article explains them, where AI helps and misleads inside a company, and the risks we watch for.
When we weigh product depth vs feature count, we choose depth. Feature count measures inventory: how many buttons, modes and models a product can list. Depth measures whether work actually finishes: whether a workflow covers the real task, works reliably on supported inputs, recovers when a step fails, returns a result you can check, keeps its context between sessions, and lets you control what it touches. AI products are unusually prone to feature sprawl, because every new model capability can become a new button in an afternoon. Ethen deliberately does fewer things per surface and tries to do each one completely. We give each kind of work one home, keep Ethen Chat focused, qualify creative workflows before exposing them, and ask a short set of public questions before adding anything. This article explains why, what we mean by depth, and what the choice costs.
Ethen V4 is the name we use for the previous generation of Ethen, when more capabilities shared fewer places. Since then, as of October 2026, we have changed six things. Every capability now has one canonical home. Chat, Code, Studio, Research, Designer, Founder, the Platform products and Desktop are separate surfaces for separate kinds of work. A shared reliability foundation sits underneath them: durable jobs, completion that depends on evidence, honest handling of unknown outcomes, and approvals bound to specific actions. Model knowledge is organized by family, with missing facts shown as unknown. Research and releases follow explicit evidence discipline. And each surface has been simplified. Several migrations are still open, and this record lists them. It describes changes documented in our published posts; it is not a launch announcement.
Ethen V5 is the next generation of Ethen, and it is a rethinking of how Ethen is organized and what it promises rather than a visual redesign. The direction has seven threads that move together: specialized products for different kinds of work; a shared foundation for trustworthy, reliable AI work; model intelligence that helps people choose models with sources; research that informs products through labeled evidence; creative work organized as workflows; autonomous work delegated as jobs with approvals and checked outcomes; and long-term coherence across every surface. This is not a dated Ethen V5 roadmap. We do not publish milestone schedules, because each step is gated by its own evidence rather than a calendar, and each product is announced only when its release evidence exists. This article explains the direction, the principles behind it, and how to follow it.
Ethen V5 rebuilds seven areas of Ethen: the boundaries between products, the durability of long-running workflows, the model experience, how research connects to products, reliability and evidence, support for long-form work, and the design language that ties every surface together. Each area is being rebuilt for the same underlying reason: AI work is getting longer and more consequential, and a structure designed for quick answers does not fit it. Because direction is easy to mistake for a launch, every item in this article carries one of four labels — shipped (public today), being rebuilt, research direction, or future exploration — and the labels reflect what our published posts document as of October 2026. Most of V5 is being rebuilt. Some parts are public today. Some ideas are research and may never become product. This article says which is which.
Most predictions about the future of AI assistants in 2027 are lists of capabilities. Ours is a description of an experience. By 2027 we want Ethen to feel calm — it informs without demanding attention and speaks up when something matters. Powerful without clutter — deep capability that appears when the work needs it. Coherent — one account, one set of controls and one way of showing status across every surface. Trustworthy — it shows what it did, what it checked and what it does not know. Fast — instant for simple things, with honest progress for long ones. Specialized but connected — each kind of work has a surface built for it, and work moves between them without starting over. And good at both simple and complex work — a quick question and a week-long project should both feel natural. We want that to hold for everyday users, creators, developers and organizations alike. This is a vision, not a product specification: it names no features and no dates.
Ethen's product design follows ten principles. Clarity before decoration: say what something is and what state it is in before making it attractive. Specialized interfaces for specialized work: each kind of work gets a surface shaped for it. Evidence over vague status: "done" means checked, and unknown is shown as unknown. Progressive complexity: a clear first step, with depth one level down. Restrained visual design: a neutral palette and a single accent. Strong typography: hierarchy carried by type and spacing. Useful defaults: a sensible choice already made, and visible. Visible control: people can see and bound what AI may touch and spend. Consistency across products: the same words, controls and status everywhere. And technical depth without clutter: detail available, not imposed. Several of these AI product design principles are familiar from decades of interface research; what changes with AI is that the system's output can look finished when it is not, so honesty about status becomes a design problem rather than only an engineering one.
When people compare specialized AI interfaces vs chat, the honest answer is that chat is an excellent interface for conversation and a poor one for most other kinds of work. Creating an image series, changing code in a repository, running an investigation over weeks, delegating a job that runs while you are away and letting an agent act on a computer each need different things on screen. They differ in what you are looking at, how long the work takes, how you judge progress, how much is at risk and which media are involved. Ethen therefore gives each kind of work an interaction model shaped for it — a thread for conversation, a canvas for creation, a workspace with evidence for code, a research workspace for investigation, a job view for delegated work, and a session with bound approvals for action — and connects them with a shared identity: one account, shared memory and permission controls, a common vocabulary for status and evidence, hand-offs that carry context, and one design language.
An approval that says "yes" to the wrong action is worse than no approval at all. Here is how Ethen's computer-use path ties each decision to one exact action.
A workflow-first checklist for deciding when a general chat, a specialized app, a control plane, or local execution fits — using Ethen's stated product boundaries.
Ethen keeps a human in the loop for AI agent actions that are consequential, hard to undo, visible to others, or outside the scope a person delegated — because those are the actions where a model's mistake, a misunderstanding or a manipulated instruction does real damage. Approvals are not a blanket requirement on every step. Asking for permission constantly defeats the purpose of delegation and teaches people to click "approve" without reading. So Ethen's approach has three parts: decide approval requirements by kind of action, not by agent; make each approval bind to the exact action it covers, so a "yes" cannot be stretched to something different; and keep some powers — such as changing permissions or policies — out of agents' hands entirely.
For an AI agent, "done" should mean that every requirement of the task has been met and that something other than the agent's own report shows it. Precisely: a task is complete when each required obligation is supported by evidence at the level of checking it needs — a passing test, a reconciled record, a confirmed delivery, an approved review — or has been explicitly waived by the person who owns the task. Three refinements make the definition usable. Keep execution success (the steps ran), task success (the outcome was achieved) and business success (it produced value) apart. Treat success as provisional until it can no longer be reversed. And report partial and unknown outcomes as what they are, instead of rounding them up to done.
Ethen treats AI actions that can't be undone — sending an external message, paying a third party, permanently deleting data, accepting legal terms, disclosing data outside where it is allowed to go — as a separate class of action with its own rules. The approach starts with one question asked before any action: if this is wrong, what does it take to make it right? Actions are classified on a reversibility scale. Where Ethen controls the system, it tries to move actions toward the reversible end with previews, staging and undo windows. For what remains irreversible, a person approves the exact action, the action is performed once with an identifier tied to its intent, and its effect is confirmed afterward. Powers that would undermine every other control — changing permissions, changing policy — are not delegated to agents at all.
"My Ethen" is our working name for a personal Ethen experience: the place where your preferences, memory, projects and the things you have asked Ethen to handle come together, across your devices. It is a direction, not a launched product, and its final form and name may differ. What we can describe now is what we want it to feel like. It should feel yours — memory and data you can see and control. Continuous — one you across phone, laptop and desktop. Useful — it helps you finish things rather than keeping you talking. Calm — it speaks up when something matters and otherwise stays out of the way. Honest — it says what it doesn't know. Bounded — it asks before it acts on your behalf. Accessible — usable by everyone. And predictable — no surprise costs. Just as deliberately, it should not be an engagement machine, a companion designed for attachment, autonomous for its own sake, or an avatar first and a helper second.
A voice AI assistant for work is most useful when it is the same assistant you already type to, not a separate one. In Ethen, voice is a way in: you talk instead of type, but you work with the same account, the same projects, the same permissions and the same approval steps. Voice is strongest for thinking out loud, capturing ideas and tasks, asking quick questions and working when your hands or eyes are busy. Text and visual surfaces stay better for comparing options, reviewing code or tables, and approving anything consequential. This article explains where voice belongs in Ethen, what stays constant when you switch modes, how a voice session starts today, and what we are deliberately not promising.
We decide between blog, documentation and research by asking what the reader came to do. If they want to use something — set it up, call an API, complete a task — it belongs in Docs. If they want structured facts about a model, it belongs in the Model Library. If they want to know what was found or proposed, it belongs in the Research Lab, typed and labeled with its evidence status. If they want to understand what Ethen is building and how it works, it belongs on the Blog. And if they want to know who Ethen is and why it makes the choices it does, it belongs in Company publishing. Each surface has its own evidence standard and freshness rule, and one topic can appear on several surfaces as long as each page owns one question. This article explains the rules and why they matter.
The practical answer to how to verify AI output is to check claims, not paragraphs: split an answer into individual statements, open each source, find the exact sentence that supports each statement, make sure the support comes from independent sources, and keep anything you could not confirm labeled as unconfirmed. That works, but it is slow, which is why most AI output goes unchecked. Ethen's approach is to make verification cheaper by building it into the output. Research reports attach a status and the supporting passages to each claim, and say plainly what the check cannot do. Model facts without complete provenance show "Unknown" instead of a guess. Agent work is marked complete only after a separate verifier checks it. Verification capacity is reserved before work is spent. And releases come with scoped evidence. This article explains each mechanism, its limits, and what you should still check yourself.
Good AI safety user experience starts from a simple observation: most of what keeps an AI product safe in daily use is something the user can see or do. They see what the AI is allowed to touch in a task. They see a preview of a consequential action and approve that exact action. They watch progress and can stop or take over. They are told honestly when an outcome is unknown rather than given a guess. And afterward they can see a record of what happened and recover from mistakes. Safety measures that users cannot see or use tend to be ignored, misunderstood or worked around. So Ethen treats safety as part of the product experience, designed with the same care as any feature, while keeping some protections — such as credential handling — deliberately invisible. This article explains that approach and where it shows up in Ethen today.
By responsible AI autonomy, we mean an AI system that acts on its own only as far as two things allow: the authority it has been given for the task, and the reliability it has demonstrated on that kind of task. Within those limits it can work independently. Beyond them, it asks. And throughout, it stays visible, so people can see what it is doing; interruptible, so they can stop it; accountable, so every consequential action traces to a decision and a record; and recoverable and honest, so failures are surfaced and repairable and unknowns stay unknown. Responsible autonomy is not maximum autonomy, and it is not a requirement to approve everything. It is autonomy that is earned per kind of task, with evidence, and that contracts again when the evidence says it should. This article explains each part of that definition and how it shapes Ethen.
The main difference between consumer and enterprise AI products is not what good AI work requires — it is who decides and who owns the data. A person using Ethen for their own projects and a company using Ethen across a team need the same things underneath: work that can be checked, precise approval before consequential actions, honest handling of what the system does not know, memory people can see and control, and a record of what happened. What differs is ownership and defaults. In personal use, the individual decides and owns their data. At work, the organization sets policy, within the law, over work data and work actions. Building for both is teaching us to keep the core identical, make ownership explicit, start every capability with strict defaults, and refuse incentives — like engagement optimization — that would serve one audience at the expense of trust in both. This article shares those lessons.
An AI creative workflow is a chain of steps, not a single prompt. Real creative work moves from a brief, to several generated options, to a person's choice, to edits that keep some things and change others, to animation or adaptation for different formats, and finally to delivery. Each step depends on what came before. That is why Ethen Studio is becoming more workflow-oriented: so that the brief, references, chosen outputs and decisions carry forward from step to step; so that consistency across assets comes from shared references rather than luck; so that spend is quoted and reserved before work runs; so that a failed step can be resumed or reconciled rather than restarted; and so that a chain that worked can be run again with new inputs. Parts of this are already in place in Studio's published media pipeline. The rest is direction, which this article describes without dates.
A multimodal AI creative system treats image, video, audio and speech as parts of one piece of work rather than four separate tools. Most real projects cross modalities: a product video needs a script, a voiceover, visuals, music and captions, and every one of them has to match. So the way we think about it at Ethen is simple: the modalities should share a system underneath — one project, one set of references and identities, one record of rights, one model for spend and receipts, and accessibility outputs such as captions and alt text as standard — while each modality keeps its own inputs, costs and quality checks. The handoffs between modalities are where most of the value, and most of the errors, live. And using anyone's likeness or voice requires explicit rights. This article explains that view, what exists in Ethen today, and what is direction.
The difference between digital robots and physical robots is where they act, not what they need to get right. A digital robot is an AI agent that perceives, plans and acts inside software — browsers, applications, files and services — under a persistent identity and bounded authority. A physical robot does the same in the physical world, with motors, sensors and real objects. Both have to pursue goals over many steps, act on incomplete information, notice when something has gone wrong, recover, stop when they should, and prove that a task is actually done. Ethen researches those shared problems in software first, because software environments can be reset, observed and checked far more cheaply and safely than the physical world. Some of what we learn may transfer to physical robots. Some of it — motor control, force, contact and physical safety — does not transfer at all. This article explains the reasoning and the limits.
The Ethen Robotics Research Lab is a research direction, not a hardware program. It studies the problems every acting agent faces — pursuing goals over many steps, understanding the state of its environment, predicting what its actions will do, recovering when they go wrong, knowing when to stop, and proving that a task is done — and it studies them in software first. Its research questions run from near-term work on reliable action in software, through skills that survive changes in models and tools and digital state models that predict effects before acting, to the far-off question of grounding any of this in the physical world. Physical work, if it ever happens, would come through integration with existing systems, ground truth gathered with partners, and control only by qualified robotics and safety teams under recognized standards. No products, partnerships, dates or results are announced here. This article explains what the Lab studies and how we think about the path from screen to physical world.
A small AI research lab can now do work that once needed a much larger team, because AI agents can search and summarize literature, draft and restructure documents, check consistency and citations, produce figures and scaffold experiments. That is how Ethen Research Lab operates. But agent output is not evidence, and a lab that produces more than it can check produces volume, not knowledge. So the operating model rests on three commitments. People own the questions, the judgment about evidence, the methods fixed before results, and the decision to publish. Agents do bounded labor inside those decisions. And the safeguards — a registry of checked sources, automated checks, review by someone who did not produce the work, protocols published before experiments, and evidence labels on every publication — have to scale as fast as the output does. This article explains that model, where agents help, where they mislead, and what we would advise another small lab.
Using AI agents in software development has changed how Ethen is built, but not in the way people usually expect. The biggest change is not raw speed. It is where human attention goes. Agents now do much of the mechanical work — exploring unfamiliar code, implementing scoped changes, writing and running tests, and drafting reports of what they did. People spend more of their time defining tasks precisely, reviewing the evidence an agent produces, and deciding what is claimed, merged and deployed. Every agent-made change has to carry an evidence report saying what ran, what passed and what did not run, using the same status words as our release certificates. And no agent merges or deploys to production without explicit human authorization. This article describes that practice, what the research says about AI-assisted development, and what we have learned.
A research agenda for AI agents that learn only from experience that is verified, rights-cleared and shown to transfer across tasks, tools and model generations.
A technical report proposing the Work Receipt: one signed record of authority, actions, effects, verification, cost and rights for every unit of autonomous AI work.
A position paper reframing AI model routing as an execution-configuration decision across model, context, tools, verification, recovery, cost and risk.
A research proposal for Skill IR: AI agent skills as portable, testable capability contracts with permissions, verifiers and compatibility records.
A benchmark design for AI agents that take action: executable environments, state-based verification, cost reporting, permissions, recovery and reproducibility.
A benchmark design for evaluating AI agents under failure: stale state, tool errors, unknown effects, interrupted actions, partial completion and safe stopping.
A research protocol for the AI agent context budget: dose-response curves for five context strategies, with obligation retention and revoked-data exposure.
A research protocol for recovery transfer: does agent recovery knowledge carry to unseen APIs, tool versions and failure mechanisms, including when to stop?
System card for one offline enumeration of a pinned Ethen build: 197 conditions, 194 passed. Not a paper and not a security disclosure.