The scan-decide-execute problem
Most current AI-driven UI automation — Cowork, browser agents, similar tools — uses a scan-decide-execute pattern. AI watches the screen at every step and chooses the next action. Non-deterministic by design; every step is an interpretation choice. Slow because each step is an inference call. Hard to audit because the decisions are happening in the model's weights at runtime. Can fail in unpredictable ways because two visually similar states might get different decisions.
Proxy's pattern: scan-code-execute
Proxy's pattern is structurally different. Each action is a module — a deterministic routine that handles a specific action without AI involvement at runtime. The AI is involved once, at the point where it has to write the routine; after that, the routine runs deterministically.
Code-speed. Code-auditability. Code-reproducibility. Failures are reproducible because the code is the same code each time.
Scope: any digital interface
Anywhere there's a digital interface a person could operate, Proxy can scan, generate code against, and execute.
Web applications. Native applications running on the user's machine. Cloud platforms. Internal tools. Industrial control panels. SaaS dashboards. Bespoke organisational interfaces. The mechanism doesn't depend on the interface being a web page; the same scan-code-execute pattern works against any digital interface.
Three execution modes
- On-demandRun a Proxy automation when needed. "Book me a flight to Geneva for Tuesday." "Pull this morning's queue and triage by priority."
- ScheduledRun on a defined schedule. "Pull the daily sales report at 8am every weekday." "Reconcile the spreadsheet against the source system every Friday."
- TriggeredRun on event detection. "When a high-priority ticket lands, kick off the response workflow." "When inventory drops below threshold, place the reorder."
The same architecture handles all three modes; the difference is just when execution gets initiated.
Modular structure with built-in failure detection
Each page action is a module — discrete, bounded routines that handle specific actions. Click this button. Fill this form. Extract this field. Navigate this menu. Each module has a defined contract.
When a module runs, it knows whether it succeeded or hit something it doesn't recognise. The ability to call for help isn't an afterthought — it's part of the module's design.
Self-healing through Forge
When help is called, Proxy diagnoses and tweaks the affected module by calling Forge. AI re-engages — not to drive execution, but to repair the specific module that failed. Examines what changed, generates an updated routine. The tweaked module gets validated and replaces the broken one.
The system gets more robust over time. Each environmental change Proxy encounters and patches becomes accumulated capability. The longer Proxy runs against a target, the more it has handled, and the rarer call-for-help events become.
In steady state, Proxy is code-speed. When the environment changes, AI re-engages only to repair the affected module. Same architectural pattern as Forge's worker-and-triage discipline and Guardian's exception escalation: deterministic happy path, structured escalation when the happy path breaks.
Modules feed back into the engineering substrate
Proxy modules and the techniques they encode become validated patterns flowing back into the engineering substrate, available for reuse in future Forge builds. The platform's productive capacity grows through what Proxy learns to handle.
Status
Design complete. The architectural pattern is committed. Forge will build Proxy in a single session when the build is initiated.