How CREAO made TinyFish its Default Web Layer
At a glance
- Company: CREAO, an AI agent platform for building and running agents that automate work end to end.
- Use case: Page fetching, scholarly search, and strict-recency news for every CREAO agent
- Previously: Firecrawl, offered as a per-user connector that most users never turned on
- Now: TinyFish Search and Fetch power CREAO’s default web layer, with Firecrawl still available as a connector
- Why: Batched fetching, agent-readable output, citation metadata, and a hard freshness window on news
- Result: 10x daily volume from 10x the users in the first three days of default-on, with request success holding steady and per-page latency roughly halved
Company overview
CREAO builds your agents, runs your work, and compounds your knowledge around the clock. A user describes a task in plain language, and CREAO writes the logic, runs it, and connects to real accounts across its integrations. When a session produces something worth keeping, it becomes an agent app that runs on a schedule.
The agent is available to every CREAO user, and its default tool set is designed to work without requiring users to configure every underlying capability themselves.
TinyFish sits inside that default tool set as CREAO's web layer. When an agent needs to read live web content, search scholarly literature, or retrieve news inside a strict freshness window, it uses TinyFish.
The problem
CREAO had two separate web needs to solve: making public-web reading reliably available to every agent by default, and adding research capabilities its existing search layer did not cover.
For web reading, CREAO already offered Firecrawl as a per-user connector. That worked for users who enabled it, but because it was opt-in, it was not something the default agent could assume would always be available.
The Firecrawl shim was still present in every sandbox, which meant an agent could attempt the tool even when the user had not connected it and hit the authentication boundary mid-task. The issue was not whether Firecrawl could read a page. It was that an opt-in connector could not serve as a guaranteed platform primitive.
“There was no way to treat ‘read this page’ as a guaranteed, always-available primitive, which is what an agent platform actually needs.”
Peter Pang, CTO & Co-founder, CREAO
Research had a different gap. CREAO’s existing web search worked for general queries, but left two important capabilities uncovered. It couldn’t guarantee a hard freshness window for news, and it couldn’t return the scholarly metadata needed for literature research, including authors, venue, year, citation counts, and PDF links.
CREAO needed both: a default web-reading layer its agents could rely on, and purpose-built search for news and research. That’s where TinyFish came in.
Why CREAO integrated TinyFish
“TinyFish fit the way CREAO agents already work. That meant we could add web capabilities without building a large amount of intermediary infrastructure around the API.”
Peter Pang, CTO & Co-founder, CREAO
The specifics behind that:
- Fetch returns content that goes straight into model context. Rendered, cleaned Markdown with navigation, ads, and scripts stripped. JavaScript executes first, so single-page apps return content rather than blank pages.
- Batching matches how agents work. CREAO can fetch up to ten URLs at once, with failures isolated per URL. One blocked or paywalled page doesn’t take down the rest of the batch.
- Search and Fetch are built around agent intent. Both accept natural-language purpose, so the agent can pass not just what it wants to retrieve, but why.
- One integration covers both surfaces. Search and Fetch share authentication and failure handling, so adding the second surface required no new secret, subprocessor review, or supporting infrastructure.
- Search adds the research primitives CREAO was missing. Scholarly results include venue, year, citation count, and direct PDF links, while news search supports a hard publication window for strict-recency queries.
The switch itself was a drop-in that took an afternoon.
Where TinyFish fits
Two TinyFish API surfaces power three agent tools inside the CREAO agent:
| CREAO tool | TinyFish surface | What it does |
|---|---|---|
| web_fetch | Fetch API | Reads up to ten URLs per call. Renders JavaScript, strips page furniture, returns clean markdown, HTML, or a structured document tree, plus the page's outbound links |
| paper_search | Search API, domain_type=research_paper | Searches scholarly literature with authors, venue, publication year, citation counts, and direct PDF links |
| news_search | Search API, domain_type=news | Searches news inside a hard publication window |
The user sees the result rather than the mechanism. Scholarly and news searches appear as cited-source cards, while web_fetch lets the agent open the underlying pages, quote them directly, follow links, and work with the actual page content instead of search snippets. paper_search can also hand the agent a direct PDF to read in full, grounding research in the paper itself rather than just its abstract.
Since August 10, 2026, web_fetch has been CREAO’s default path for public web scraping. Firecrawl remains available as a user-connected option, while TinyFish gives the default agent a web-reading capability it can rely on without individual setup.
Under the hood
CREAO also built the TinyFish integration around the constraints of running agents in production.
- Credentials stay outside the sandbox. CREAO agents run in ephemeral sandboxes, but the TinyFish key never enters them. Requests are routed through CREAO’s trusted host, with permissions re-checked at call time.
- Results adapt to the active model. Instead of using a fixed content cap, CREAO sizes Fetch results against the model’s available context and distributes that budget across URLs in a batch.
- Long documents stay resumable. Continuation reads use a fifteen-minute cache window so the next chunk comes from the same version of the document rather than a fresh crawl. CREAO verified this end to end on a 454,442-character specification.
Key outcomes
10x the users, 10x the volume. Under the previous opt-in web-reading model, the Firecrawl path handled around 70 scrapes a day from 57 users who had ever connected it. In the first three days after web_fetch became default-on, CREAO was running 700–800 calls a day across 1,200–1,600 URLs from 593 users.
“Once web reading became a default capability instead of an opt-in, usage grew on its own.”
Peter Pang, CTO & Co-founder, CREAO
Reliability held as coverage expanded. Request success stayed effectively flat, moving from 99.95% to 99.83%, while web reading expanded from an opted-in subset of users to the broader user base.
Per-page latency roughly halved. The previous Firecrawl path ran at p50 1.6 seconds per page, one page per call. web_fetch runs at p50 2.0 seconds per call while averaging two pages.
Research became a new built-in capability. paper_search and news_search have handled 5,600+ requests at 99.8% success. Strict-recency news search and scholarly search were capabilities CREAO did not have before TinyFish.
From integration to production in days. The initial switch was a drop-in that took an afternoon, and web_fetch went from dark launch on August 7 to the default public-web scraping path for every user on August 10. It now sits behind a deploy-gate test that must pass before CREAO promotes to production, and TinyFish is listed in CREAO’s public subprocessor documentation.
What’s next
CREAO is extending the same web layer into more specialized agents, starting with a complete SEO and GEO analysis agent.
TinyFish Fetch reads and structures the pages under audit, while Search checks how those pages actually surface for real queries. The first supporting piece, a PageSpeed audit tool, went live on August 12.
As CREAO builds more of them, TinyFish stays underneath as the layer that lets those agents search and read the live web.
Building an agent that needs to understand the web before it can act?
