Evonx is organised around one loop: idea to running preview.
That sounds like a slogan, so here is the concrete version. Every surface in the product answers the same question — does this make the distance between "we should build this" and "here it is, running" shorter? The four described below are not separate features that happen to ship together. They are four sides of the same loop, and each one is shaped by the others.
The four surfaces
Previews. Every change gets its own isolated runtime rather than a slot in a shared staging queue. This is what makes the output of a step something you can click instead of something you have to read. The reasoning behind the isolation model is in preview hubs.
Evolution threads. Stepwise execution, resumable across sessions, with decisions recorded as decisions rather than buried in a transcript. Threads are what let work span weeks without a re-briefing every time you come back. The structure is in how Evonx structures evolution threads.
Design. Wireframes and mockups are produced inside the thread and constrained by the design system already present in the codebase, rather than generated from generic defaults. The argument for treating tokens as inputs is in design systems agents can follow.
Publishing. Changes arrive as pull requests you review like any other. No implicit merges, and no environment that quietly diverges from the repository.
Two decisions that shaped the rest
One-shot generation is not the default for substantial work. The obvious design is: ask for a feature, get the feature. It demos well and reviews badly. A large generated change leaves you with two options, trusting it or discarding it, and neither is a good place to be. Advancing a thread one step at a time looks slower written down and tends to be faster in practice, because every step is small enough to actually check. This is also why the scope gate comes first among the engineering gates.
Waiting breaks the loop more than a missing feature does. If a preview takes minutes to appear, you go and do something else, and the context you were holding is gone by the time you return. That makes environment start-up a product concern rather than an infrastructure detail — it decides whether the loop is something you stay inside or something you dip into. A lot of unglamorous work sits behind that, and it is the right place for it to sit.
Both decisions point the same way: the useful unit is not the largest change an agent can produce, it is the largest change a person can confidently accept.
What Evonx does not do
Evonx does not merge its own work. It is technically straightforward to let an agent do that, and the resulting product is not one we would want pointed at a real codebase. The gates are the point, not friction to be optimised away.
It also does not guess at context it cannot see. An agent that invents a plausible file path is worse than no agent, because it forces you to read everything it produces with suspicion. When the grounding is missing, the right behaviour is to ask — which is the principle behind how the agent reads before it writes.
Where this goes
The direction is more of the same rather than something new: shorter previews, better grounding, and continued work on making a thread something a non-engineer can meaningfully participate in. That last one matters most. The person who understands the workflow — the ops lead, the accountant, the person who actually knows which edge case is real — is usually not the person writing the code, and every step that requires reading a diff shuts them out of their own product.
A loop that only engineers can close is a smaller loop than it needs to be.