Under the engine: 3.5 million packets per second, and the VPC blinked first

Founder life is pitch decks, patent attorneys, and pipeline. All of it matters. None of it is the reason I started building Mayagentic.

This is: packet forwarding at near line rate, and finding out where it breaks at scale. On Linux, which has been my favorite platform for as long as I can remember.

Last week we found out where it breaks. It wasn't Maya.

The number

3.5 million packets per second on a mid-size AWS box. The test rig kept pushing until the VPC fabric itself started throttling agent traffic. Maya's data plane never crossed 10% CPU.

There is no feeling like watching the fabric throttle before the code does. But the number isn't the point. How it's possible is the point, because the how is what makes Maya deployable in places where a slow governance layer would be quietly turned off.

Under the engine

The speed is not magic. It comes from three decisions we made early and refused to compromise on.

The kernel does the work. Maya's data plane is eBPF. Every packet is classified, attributed to its agent, and policy-checked in the kernel — before a single byte reaches userspace. There is no proxy in the path and no TLS termination. Zero bytes copied, zero connections re-terminated, nothing decrypted. Payload-blind isn't just a privacy stance; it's why the fast path stays fast.

Structs are aligned to cache-line boundaries. The maps the kernel consults are laid out to fit 64-byte cache lines, and they're mirrored byte for byte between the C on the kernel side and the Go on the control side — verified in CI, so a drifted field can't silently cost us a cache miss (or worse, a misread packet). When you're handling millions of packets a second, memory layout is the difference between headroom and heat.

Policy decisions are lookups, not rule evaluation. There is no rule engine grinding through conditions in the hot path. The identity a lookup needs is already on the packet when it arrives, so deciding whether a connection is allowed is a map lookup: the work was done when the policy was written, not when the packet showed up.

And yes — all of it written in vi, tested from bash. What's so funny about coding with vi and bash?

Why speed is a security property

Here is the part that isn't about engineering pride.

A governance layer that costs milliseconds ends up with an exemption list. First the latency-sensitive service gets waived out, then the high-throughput one, and within a quarter the "coverage" slide has an asterisk on it. Every security engineer has watched this happen.

Line rate at single-digit CPU means the security-versus-performance meeting never gets scheduled. There is no trade-off to argue about, so there are no exemptions, so the map of your agent traffic stays complete. The performance work is the security work.

Agents move fast, and they are only getting faster. The thing watching them has to be faster still — even if it was coded in vi.