Designing software around many small decisions
Parallel checks, conditional steps, numeric controls and complete action plans. A playbook for turning model judgments into useful interactions.
A browser agent is trying to find a dress in the right size and color. The page is still loading. A catalog response arrives, followed by inventory, navigation data and a script that happens to mention the inventory endpoint.
The agent needs several different operations. Recognize the relevant response. Read the actual stock. Check the price. Choose whether to add the item to the cart. Confirm that the resulting reservation concerns the same item.
The work has different shapes:
- Parallel: examine independent responses as they arrive.
- Conditional: inspect stock after finding the relevant product.
- Deterministic: compare an exact identifier, size or price.
Designing those relationships changes the product a person can use.
This article develops reusable patterns from our controlled prototypes. The public demos replay tested cases. The larger applications below are designs to build and evaluate, with their proposed behavior identified as such.
Let independent evidence arrive independently
In a resource stream, a question can accompany each response. Product data, availability and a planted development credential are different predicates over the same incoming material. Each result retains the resource and question it evaluated.
resource stream
├─ response A → product? / availability? / credential?
├─ response B → product? / availability? / credential?
└─ response C → product? / availability? / credential?
↓
results keyed to their sources
The user-facing difference is concrete. A browser agent can begin its next useful step when the needed evidence arrives. An unrelated request can still be loading. A stalled analytics resource does not have to delay the discovery of a product identifier.
Bound the parallel work. Choose a maximum queue and a maximum number of active checks, and preserve cancellation when the task changes. A full queue needs an explicit policy:
- Stop accepting more work until capacity becomes available.
- Retain a bounded sample, with the sampling rule visible.
- Prioritize resources relevant to the next required gate.
Each policy changes the evidence the agent will have.
LOTUS develops a data-processing vocabulary for semantic filters, joins and other operations over collections. Its distinction between an operator’s intended behavior and the plan used to compute it is helpful here. “Find responses carrying availability” is one requirement. The batching, model choice and scheduling that implement it are further decisions, with consequences for cost and result quality.
Make later work conditional on an answer
A product match is a reason to look for its inventory. Inventory showing the required size and color is a reason to consider a cart action. A matching reservation is a reason to proceed to the next checkout step.
recognize catalog response
↓ match
find the relevant inventory
↓ same product
check size + color + stock + price
↓ all required checks pass
add to cart → verify matching reservation → continue
In our controlled browser-agent design, semantic resource decisions are model work. Parsing the known fixture, comparing exact product IDs and applying stock or price conditions are ordinary code. Their combination supplies the next action. An unresolved condition keeps the agent at the relevant step with the evidence it has.
This pattern could support an agent testing a company’s own checkout. The agent would navigate the workflow, recognize responses associated with shipping, and compare the chosen option with the resulting order state. A second branch could inspect the resources for accidental credential exposure. Both branches share observations; each has its own completion condition.
SayCan offers a related lesson from robotics. It combines a language model’s assessment of useful skills with learned estimates of whether those skills can succeed in the current state, then repeats the choice after execution. Our browser gates use different mechanisms. The architectural connection is the separation between a plausible next step and the conditions that make it executable now.
Give a finite decision an exact numeric meaning
Many useful requests combine a qualitative direction with a quantity: a little wider, twice as long, halfway back.
Consider a proposed canvas controller with three permitted width changes. A model can choose small, medium or large; a deterministic mapping can turn that choice into an operation over the current width.
| Model choice | Tool operation | Width from 240 px |
|---|---|---|
| Small increase | multiply by 1.1 | 264 px |
| Medium increase | multiply by 1.25 | 300 px |
| Large increase | multiply by 1.5 | 360 px |
The table is an illustrative design, not a measurement or the current canvas action list. Its purpose is to make the interface between judgment and arithmetic explicit. The tool can then check the result against the available space and preserve the previous width for undo.
Another design can first select a range, then refine within it. A coarse decision chooses which part of a permitted interval is relevant; a second decision chooses a position within that interval. Each additional level consumes time and can compound an earlier mistake. Use another level only when the finer distinction changes the experience.
Units remain part of the contract. Our instrument work uses native parameter meanings when interpreting a relative envelope change. Halfway between two release times in milliseconds can differ from halfway between two normalized control values when the control’s mapping is nonlinear. A known conversion belongs in the tool, where it can be tested exactly.
Research on parameterized action spaces studies the combination of discrete actions and continuous parameters in a different setting: simulated robot soccer. The useful connection is the structure of an action. Choosing what to do and determining with which parameters can be distinct parts of one executable result. The deterministic mappings proposed here do not require adopting that paper’s reinforcement-learning method.
Choose compatible changes together
“Make this a monophonic lead with glide” can concern several instrument controls. Independently choosing the most likely value for each control may produce a combination that never represented a coherent plan.
Our native-instrument prototype selects a complete permitted edit plan. Protected controls constrain the candidates. The tool applies the chosen plan, checks the resulting native state and renders audio for comparison. The tested examples include coordinated voice and glide controls, compound envelope changes and refusals when a protected control prevents an edit.
current state + protected controls
↓
permitted complete plans
↓
model selects plan
↓
apply + check all 80 controls
↓
matched audio comparison
↓
accept / refine / restore
This is a sequence of different kinds of work. The constraint filter and state checks are deterministic. The model chooses among plans. The plug-in renders the sound. Calling every box an agent would hide the useful engineering decisions.
For a proposed packaging tool, the same pattern could select a coordinated change to label position, font size and spacing. A valid bundle would respect the relationship among those dimensions. The designer could inspect one coherent proposal instead of repairing a set of individually plausible edits.
Reduce a collection into a specific next action
A row-level judgment and a collection-level conclusion answer different questions.
Suppose a workshop receives twelve enquiries for the same weekend. Independent checks could identify which enquiries need an electrical specialist, which lack basic bike details and which describe routine mechanical work. A reducer could count the cases needing follow-up and gather their IDs. A later step could prepare the corresponding questions for staff to review.
enquiries → bounded parallel classification
↓
group source IDs by outcome
↓
missing details? → prepare follow-up set
specialist work? → prepare referral set
↓
staff review
The reducer should have an explicit meaning: any, all, a threshold, a count or a bounded collection. An empty collection needs a defined outcome. A missing response needs to remain distinct from a negative result. Exact counts come from code; a further interpretive comparison can be another model task.
This proposed arrangement changes the staff experience from opening every message to reviewing a small set of relevant next actions. Its evaluation must still examine individual misclassifications and what their aggregation causes. One wrong exclusion can matter more than many correct routine cases.
We exercised this structure in a small runtime test. Two authored items carried explicit expiry flags. Parallel item decisions fed an any reducer; a risk result admitted a review decision; the final task selected a complete disposition. Simple flags made the expected execution path unambiguous.
| Constructed input | Actual model calls | Conditional review | Final effect |
|---|---|---|---|
| Two items, one expired | 4 | Runs | Hold; priority 3; review window 90 seconds |
| Two items, neither expired | 3 | Skipped | Clear; priority 0; no review window |
| Empty collection | 1 | Skipped | No release |
All three expected traces and effects passed. The reducer made no model call. The numeric fields came from the selected action’s fixed mapping, and were returned together. This is development evidence for these execution paths; it makes no claim about general language accuracy or production throughput.
Join findings when their meaning depends on each other
Our application-review example exposes a different dependency. An application can correctly show repeated customer use and recurring founder involvement. Presenting the use finding alone makes it easy to mistake that recurrence for independent product operation.
The evidence compiler has explicit rules:
- A conflicting finding must retain its actual contradictory source.
- Repeated use combined with founder-operated or mixed delivery carries the separately accepted operating finding’s source as a caveat.
- A counter-citation that does not apply to the selected finding remains in the private trace and is unused in the presentation.
The join does not change a model label or invent a source. Its dependency must pass the same evidence checks before it can be used. This gives an exact place to test the relation between two otherwise correct answers.
The result is useful at two levels. A reviewer sees what changes the meaning of repeated use. The interface can then filter and compare the prepared findings without rereading every application on each interaction. Semantic interpretation, conditional composition and immediate navigation are separate operations with separate correctness and timing requirements.
Keep decisions attached to the state they examined
The browser moves. The canvas changes. A new invoice arrives. A correct decision about an earlier state can be wrong to apply now.
Store the task revision, source identity and relevant state version with each result. Recheck preconditions before applying an edit or proceeding with an action. A later answer can update an earlier observation, while preserving why the earlier result was shown.
An action’s destination is only part of that dependency. A button edit may also depend on its container and nearby content. Keep working while model decisions arrive develops that distinction with an interactive example, conditional application and selective reconsideration of a decision graph.
The Dataflow model makes event time, processing time and result updates explicit in streaming computation. The interface consequence is useful even at a much smaller scale: an observation can arrive late, and the application needs a rule for whether to incorporate, replace or discard it.
This also changes what latency means. Measure model time, transport, queueing, tool execution and the time until a useful action becomes available. Parallel calls can shorten a group of independent checks; a chain’s dependent stages still accumulate delay. A fast label that arrives after its source has become irrelevant has not delivered a fast interaction.
Develop the model against the tool it will operate
A general model can prototype these decisions when supplied with the necessary context. Repeated operation creates another opportunity: specialize the recurring interpretation around the task and the tool’s exact semantics.
Recurring semantics can be specialized around the application:
- An instrument model can learn what its permitted plans mean.
- A canvas model can learn the relationship between a request, selected objects and available edits.
- A browser task can learn the difference between an actual inventory response and a script that merely names its endpoint.
That stable knowledge can become part of the trained decision behavior instead of being re-explained in a large prompt on every call.
Live state still has to arrive with the request. Training cannot tell the model which object is selected now, whether today’s item is in stock or which controls the musician just protected. Specialization concerns recurring meaning; current observations remain inputs.
The tool revision is consequently part of model compatibility. If “halfway back” changes units, or an outcome acquires a new executable meaning, the old evaluation no longer establishes the new behavior. Development examples, held-out evaluation, action mappings and the deployed model need to agree on the same contract. Latency, cost and accuracy improvements must then be measured on that task.
SYSTEM1 brings this development into one project: define the behavior, develop its model, build the callable tool and make the result available through an interface or embedding. The decision architectures here are ways to shape that deliverable. Their purpose is a specific new capacity: software that can examine several possibilities, resolve the relevant uncertainty and do the next useful thing while the work is still in progress.