The problem with most AI web automation isn't that the models are too dumb. It's that the architecture is too fragile.
TinyFish turns fragile browser automation into deterministic, reusable workflows — reducing cost, improving reliability, and making large-scale web automation production-ready.
A consumer browser agent can book you a flight. It handles one task, for one person, with room to fail and retry. When it breaks, you refresh and try again.
Enterprise automation has no such luxury.
When a workflow monitoring 50 insurance portals fails on step 7, you don't get a second chance to charge the same transaction. When a pricing agent collapses mid-run across 1,000 SKUs, the failure isn't one broken session — it's a cascade.
Enterprises don't buy demos. They buy systems that work under load:
The web makes this difficult. It is dynamic, personalized, rate-limited, and defensive. Models are powerful but probabilistic. Enterprises require deterministic outcomes.
Codified learning is how TinyFish bridges that gap.
Instead of asking a model to complete an entire workflow end-to-end, TinyFish breaks the workflow into small, structured steps — and only uses models where ambiguity actually exists.
Most systems treat a workflow as one task: run a browser, let a model navigate, hope it completes.
But failures are expensive, opaque, and hard to recover from.
Codified learning takes a different approach. A workflow becomes a graph of small decisions. Each decision is a node: typed, bounded, measurable.
The system doesn’t solve the entire site. It solves the next node.
When something breaks, you don’t restart the workflow. You rerun a single step. This is what makes large-scale automation stable.
This changes two things:
1. Execution becomes parallel and reusable
Nodes run independently. Results can be cached. Failures don’t require full replays.
2. Costs become predictable
Costs scale with distinct decisions — not browser time. Many decisions are reused on subsequent runs.
The more a workflow runs, the cheaper and more reliable it becomes.
Each node contains three components, and understanding the composition is what makes the architecture click.
Transforms, schema validation, navigation, data extraction, joins. Fast, cheap, testable. No model involvement unless the step is genuinely ambiguous. This is the majority of steps in any real workflow and keeping it model-free is what makes the system reliable and auditable.
For the minority of steps that require real reasoning — interpreting an unusual UI, choosing between valid navigation paths, handling a genuinely ambiguous form — a small model call executes inside a contract. It's wrapped in guardrails and fallbacks, so ambiguity at one node doesn't cascade into workflow failure at the next.
This is the "learning" part made concrete. Preferences, patterns, and decisions the system has encountered before are written down, versioned, and replayed safely. Learning here isn't fuzzy model fine-tuning. It's embedded as versioned artifacts the system can run deterministically and improve predictably over time as new patterns accumulate.
This structure directly maps to enterprise needs:
When a single model drives a browser across a 15-step workflow, a failure at step 9 means replaying steps 1–8 to diagnose it. In a node graph, a failure at node 9 stays at node 9. The upstream work is preserved. The rollback is local. This is the difference between fixing one step and rerunning an entire business process.
Node-level scheduling means a fleet of agents can be coordinated at the decision level, not the session level. Individual nodes from thousands of concurrent workflows can be dispatched, parallelized, and prioritized by the control plane. Sessions don't block each other at arbitrary workflow boundaries.
Browser-time and token-consumption pricing both create unpredictable costs as workflow complexity grows. Step-based pricing against a node graph scales with distinct decisions — many of which are memoized on re-runs. As workflows mature, more steps are reused and costs decrease.
Traces in a node graph map directly to business events. A log that says node: apply_promotion → failed → reason: selector_not_found is actionable. A log that says "model call failed at unknown step" is not. When workflows multiply across an enterprise, the difference between node-level traces and session-level logs determines whether your operations team can scale oversight proportionally.
Enterprise deployments require more than reliability. RBAC, audit trails, site-specific rate limits, change control, and error budgets all need to live somewhere structured. In a node graph architecture, governance sits in the control plane — not bolted onto individual sessions after the fact.
Consider a checkout verification workflow. A naive implementation drives a browser with a model from start to finish and hopes it reaches the correct total. When it fails, the entire run is lost and you have no clear signal about where it broke.
Codified learning breaks this into a graph:
Only 2 of 6 steps require a model.
The other 4 are deterministic, cacheable, and never need to be rerun.
A naive system replays the entire 6-step workflow every time promotional logic changes. In a graph architecture, that change is a single node update. Latency and cost stay inside budget.
The same pattern applies to pricing monitoring, scraping, and inventory aggregation, where small changes shouldn’t trigger full reruns.
They are. This is the most common objection, and it deserves a direct answer.
Better models don't replace contracts.
Even a perfect model doesn’t:
Enterprises don't just need accuracy. They need observability, change control, and error budgets. Codifying structure around models is what makes them production-usable — not just impressively capable in demos.
Consumer agents run a browser one task at a time. Enterprise web agents run hundreds of thousands of tasks simultaneously, across thousands of sites, against SLAs. The architecture has to match the operating environment and a model that reasons perfectly inside a fragile wrapper still breaks in production.
Structure is what makes models usable in production.
TinyFish's enterprise web agents are currently in production at Fortune 500 companies across hospitality, e-commerce, and transportation. For Google, TinyFish agents aggregate hotel inventory across thousands of properties in Japan, making availability discoverable through Google's hotel search without requiring infrastructure changes from property owners. For DoorDash, the agents manage competitive pricing intelligence at a scale and speed that would require a large operations team to replicate manually.
These aren't pilots. They're the codified learning architecture running millions of operations per month, with the reliability and governance enterprise contracts require. The web is dynamic, personalized, and defensive. Codified learning is what makes automation not just survive it, but get cheaper and more reliable the more it runs.
The fastest way to evaluate this is to run it on your own workflow.
Codified learning isn’t just a different approach to automation.
It’s what makes it work at scale.
Traditional browser automation tools like Playwright or Selenium execute workflows as linear scripts or sessions.
Tinyfish's codified learning breaks workflows into structured, reusable steps (nodes). Each step can be executed, retried, and optimized independently — making the system more reliable and cost-efficient at scale.
Not exactly.
While codified learning uses a graph structure similar to a DAG, the key difference is how decisions are handled. Nodes are not just execution steps — they can include model-backed reasoning, deterministic validation, and reusable heuristics.
The system improves over time by turning ambiguous decisions into deterministic ones.
Better models improve accuracy, but they don’t solve:
Even a highly capable model still operates probabilistically. Codified learning adds structure that makes these systems reliable in production.
Costs in traditional systems scale with:
With codified learning:
This means costs decrease as workflows mature, instead of increasing.
No.
Most teams start with a single workflow — such as pricing monitoring or checkout verification — and replace only that part of their system.
This allows incremental adoption without rewriting everything.
Codified learning is most effective for workflows that:
The benefits are most visible at scale, but the same structure can improve reliability even in smaller workflows — especially when failures are costly or frequent.
No credit card. No setup. Run your first operation in under a minute.
