A single prompt like "Move every overdue task to next week and let the owners know" takes seconds to type. For the AI agent executing it, that instruction expands into dozens of API calls: find the board, read every item, check dates, update each task, notify each owner. Multiply that by every agent in every workspace, and the traffic pattern shifts dramatically. At the start of 2026, monday.com's API edge was buckling under this new load. Weekly requests had grown 2.5x in a year, from 1 billion to 2.5 billion. The edge was consuming a growing share of on-call time, and the team set a hard target: the edge should add no more than 100 ms to a request at p99.
The old edge paired an Apollo Router with a Node.js coprocessor. The router handled GraphQL query planning and execution, but every business rule — authentication, rate limits, complexity budgets, API versions — lived in the separate coprocessor service. At several points in each request, the router had to stop, send the request context over HTTP to the coprocessor, and wait for a response before continuing. Every hop re-parsed the request. JSON parsing is CPU-heavy and blocks the event loop, so larger payloads meant longer waits for everything else in that process. Requests that should have been rejected immediately by rate limits were only stopped deep in the router lifecycle, after consuming resources on parsing and round trips. Business logic was tangled with router internals, making even small rule changes risky and slow.
Splitting the edge into gateway and router
The team split the edge into two layers, each with a single job. The gateway decides: authentication, authorization, rate limits, complexity budgets, versioning, agent detection, and observability run as a pipeline of small, independent steps. If a request fails a check, the gateway rejects it immediately and the router never sees it. The router routes: it plans each query, fetches from the owning subgraphs, and merges results. It enforces only the complexity budget set by the gateway, since cost estimation needs the query plan. Beyond that, the router holds no business logic.
The new router is WunderGraph Cosmo, an open source GraphQL router written in Go. The team chose it not primarily for speed but because it is easy to modify, profile, and adapt, and because they could collaborate closely with the WunderGraph maintainers. Over many sessions, they brought production profiles, bug reports, and fix ideas that shipped in Cosmo. They also run a fork with changes that reduce memory footprint under their traffic. With both layers in Go, the team profiles, patches, and extends the entire request path with a single toolchain. Go gives direct control over memory layout: data streams through rather than being held, and buffers are reused instead of reallocated. Most savings came from many small fixes. File uploads now stream straight through instead of buffering. Each response is held in memory once, not three times. Federated tracing data (FTV1) is parsed directly from the wire format, halving its share of router CPU usage.
Shadow validation against production traffic
Two GraphQL routers can both follow the federation spec and still answer the same query differently. Before any customer depended on Cosmo, the team wanted to find every difference on real traffic. The gateway, sitting in front of the old router, could safely send a sample of read-only queries to Cosmo in the background — shadowing did not affect latency. Writes were never copied, and feature flags controlled which accounts were shadowed and at what volume. Naive comparison is mostly noise: timestamps, ordering, non-deterministic fields. The team used a technique from Diffy, Twitter's open source tool: each shadowed query also went to the old router a second time. Anything that differed between the two old responses was noise by definition; whatever remained was a real difference. The real differences were edge cases in validation, null handling, error shapes, and query cost calculation where Apollo and Cosmo implement the spec differently. Each was fixed in the gateway or the fork before any customer moved. Traffic then migrated gradually behind feature flags; rolling back was a flag flip. All of monday.com's API traffic — more than 2 billion requests a week — now runs on the new edge with no customer changes required.
Latency and cost results
The time the edge adds to a request dropped from about 490 ms at p99 to 44 ms today. The median request now spends 9 ms in the edge, down from about 80 ms. The improvement came in two steps. At cutover, removing coprocessor round trips cut p99 from about 490 ms to about 200 ms. In September, reworking authorization brought the rare cache-miss check from about 130 ms at median to about 4 ms, shaving roughly another 150 ms off p99 and bringing it well under the 100 ms target. The edge also got far cheaper: 92% less CPU and 80% less memory than a year ago, while handling 2.5x the traffic. Even at 10x today's traffic, the edge would use less CPU than the old edge needed a year ago.
Optimizing for agentic flows
The team believes agents will become the main consumers of the monday.com API. They are now optimizing the edge for agentic flows: many small, fast calls made by software on behalf of a person. That is where work is heading, and the goal is to make monday.com an AI-ready platform that agents can build on. The API documentation is the starting point for developers building agents on monday.com, and the team is hiring for people interested in problems like this one.