My Summer as a Platform Engineering Intern at BrainCo

I first heard about Brain Co. last September on a flight home from my internship at a larger growth-stage AI company, while listening to an episode of No Priors where Sarah Guo and Elad Gil interviewed Jared Kushner about Brain Co., the company he and Gil had just cofounded. That internship gave me an appetite for fast-moving startups, which made me want to join an earlier stage company that I had conviction in with foundational infrastructure still left to build. Brain Co. fit that description: an AI platform for critical industries, with forty engineers at the time who’d spent long tenures at some of the most important companies of our time. I assumed a team like that wouldn’t hire interns for a few more years. Then, in February 2026, a Summer 2026 posting appeared.

Why I joined

By early 2026 enterprise AI felt crowded, but Brain Co. stood out for taking on the hard problem of deploying AI in security‑ and legacy‑constrained environments (governments, hospitals, PE portfolios) with a single cross‑vertical platform, Atlas. I originally interviewed with an AI Product pod, but after learning how much foundational infrastructure sat beneath the products (deployments, network/security boundaries, and the shared platform), I asked to switch to Platform.

The recruiting team rerouted the process, after which I interviewed with the (small) Platform group plus my eventual lead and manager. I joined the AI Platform Agentic Engineering team in June, excited but aware I was coming in with limited infra experience and expecting a modest DevX project that quickly proved far bigger.

What I built

A company-wide LLM inference cost attribution platform: usage across every provider, key, and pod, totals reconciled to the cent against vendor invoices, plus a fix for a production deployment loop along the way.

On day one, I received the codebase (our Platform monorepo plus IaC repos) and a warm‑up task: import LLM inference usage from our LLM gateway and attribute it per user. While reading, I found edge‑case aggregation bugs in our frontier-model inference metering and fixed the low‑hanging fruit. I got those PRs merged to production that same day.

On my second day, I started sketching my design for LLM gateway inference tracking. The problem was to move usage data, persisted in a database in a separate environment, into our internal application on a different environment across a network boundary. The first production version I sketched was a Python exporter that pulls metrics from the gateway’s database, a daily cron object-storage handoff, and an idempotent TypeScript importer that accepts a fixed CSV contract on the internal application side. The cronjob pulls a long-range window each run so gaps and billing changes (refunds or credits) heal themselves over time. Additionally, the Python producer rejects empty exports (a possible error state) and the TypeScript importer rejects stale windows.

Once the pipeline was live, I found the next need through conversations with my mentor and leadership: clear visibility into how teams were using LLM inference providers and frontier models across many internal keys and tools. Vendor dashboards showed only aggregate spend, so answering questions like “when did spend spike?” or “who used this key?” required stitching together multiple sources. I spent most of my internship building a generalized attribution layer for Atlas, covering company-wide usage across providers, keys, and pods.

Frontier model providers report usage and cost at different grains, with gaps in coverage.

The hard part was reconciling usage and billing. Frontier model providers report token usage per key, but cost at a different grain. Additionally, price rates vary across model families, versions within model families, and token categories (cached, uncached, input, output, etc). In addition to this, the popular frontier multimodal models are also used for non-LLM AI inference (embeddings, image generation, etc.) which is billed in unique ways for different providers. In practice, a naive token split would be wrong.

My general approach (since each provider required some bespoke patching) was to match versioned usage models to billing families and divide each vendor invoice into day/model/token-category price bands. Then I allocated the billed cents across keys active in each band, using largest-remainder rounding to keep the arithmetic in integer cents. Finally, I ensured that every per-key estimate summed exactly to the vendor total. The hardest part was reconciliation: properly handling unmatched billing lines by falling back to a coarser split.

Working on the cost drill-down was one of the most fulfilling parts of the internship. The per-tool, per-key, per-product heuristic was interesting because I had to derive a formula for this myself. I brought together messy data from multiple sources with different shapes, defined the estimator, made every split reconcile to the total, measured fallback coverage, and then presented where the algorithm was strong vs. where it lost precision at the granular level to the broader organization.

An image updater and an infrastructure reconciler both owned the same Helm parameter list, so the deployment restarted every few minutes. Deleting the redundant block stopped it.

Midway through building the internal app, I also chased a production rollout loop. The deployment restarted every few minutes, which caused overlapping versions to serve different content-hashed JavaScript chunks, leading to intermittent 404s. I found it using our internal SRE agent and log analysis, traced it to an image updater and an infrastructure reconciler fighting over a single Helm parameter list, and fixed it by deleting a redundant parameters block that gave both controllers ownership of the same field. It was safe to remove (a leftover from an earlier migration), and it stopped the thrash immediately. Bugs like this are hard to chase down, and hard for today's coding agents to fix, because they default to adding handling code for whatever they assume the problem is rather than deleting infrastructure.

Then the cluster the gateway lived on got scheduled for decommission.

After building all of this out, the final thing to work around was that our existing LLM gateway inference service itself was in a cluster that was going to be decommissioned. During the gateway cutover, I moved the usage producer into a new cluster that had recently been set up for our internal tools and tore down old services. I rebuilt the finance view for company-wide monthly AI inference usage, added an MCP interface so that employees can ask agents questions over this data, and also integrated a provider whose cost data was only available through a billing warehouse export.

This was a massive amount of scope for something that originally started with just obtaining per-user LLM inference token usage and spend.

What I learned

→ Think more about how the product gets used

The lesson I'd give anyone joining a fast-moving enterprise AI startup is to ask who the number is for.

My first design document proposed a real-time queue for our LLM inference usage tracking, and I liked it because it had a more sophisticated infrastructure setup and also updated per second. After some discussion with my mentor, he asked whether anyone needed per-second updates or whether leadership and engineers only inspect the dashboard occasionally, i.e., every day, every week, etc. So, we decided on shipping a daily blob instead. That removed a producer, queue, poison queue, staging table, rollup, deduplication, etc.

Later, when I was building the dashboard for our team-level usage, I initially wanted a perfect membership matching system that automatically matches a given employee's email to the team they're in with cent-exact allocation, and this would work as soon as someone joins the company or switches pods. However, talking to my manager, I realized that leadership just needs to see which teams were adopting the tools and where usage was concentrated in terms of verticals and pods. A simple membership source that was updated manually from our source of truth that maintains what pod a person's working in and a directional split answers that simply.

→ Preserve precision when necessary

There are some places where correctness is important. For example, the finance sheet itself used signed exact cents, failed closed on partial data, preserved manual corrections that leadership adds to the fields, and also left missing data blank. There are also other things, such as vendor credits, late corrections to the data such as refunds, partial API responses, missing months, and all of these other kinds of issues that would change the reported total.

When you're thinking about the numbers that you share, you should choose your guarantees from how each number would be used by the end user and how it affects the business rather than just chasing the engineering problem itself. By doing this, you end up solving the problem faster without making the system overly complicated.

→ Agents can only amplify what you know

The Agentic Engineering team's charter is to improve the pace of development and the agentic coding experience across the company. We mainly built agents and developer tools for the rest of the company so coding inside the team was also very heavily AI assisted. These agents help plan, implement, debug, and review changes. We build internal tools such as coding sandboxes with MCP tools setup by default and agents that would babysit your PRs.

These coding agents specifically help us move fast. They help us do things like fuzzing data boundaries, performing property based testing on infrastructure experiments, writing and running CLI scripts for tasks, rendering configuration matrices, and checking authentication in a deployed environment; these are all things that usually take plenty of time for an infrastructure engineer. However, the problem is when the premise of how you’re going to implement something is wrong, you build the wrong system just as quickly. Planning, steering, and reading the surrounding system is important. In my opinion, there are certain things that agents are calibrated toward. For example, they're not good at making the right trade-off you need for a given use case, and will almost certainly pick the most over-engineered solution or care too much about correctness or defensive engineering to the point where it's not even necessary.

→ Verify the system that shipped

The deployment loop taught me this one. Every PR that touched that service had been reviewed and passed CI, and none of that mattered, because the bug didn't live in source. It lived in the interaction between two controllers and a rendered Helm manifest, and the only symptom was users intermittently getting 404s on JavaScript chunks. You could read every file in the repo and never find it. You had to look at what was actually running: the rendered config, the restart history, the logs.

When agents let a team ship this much this fast, that gap gets wider. More changes land per day, and a growing share of the failure modes only show up in built artifacts, deployed manifests, or the behavior of a live system, none of which source review catches. So verification has to move downstream.

I ended up applying the same instinct to the agents themselves. In my last few weeks I built a dashboard that measured how our AI review bots were actually performing across every repository, per author, by reading the time-series data the bots were already emitting and correlating them against the usage data I'd been ingesting all summer.

Moving fast means more things can break. The only defense is knowing exactly what you shipped, which is not the same as knowing what you wrote.

The team

I was joining a team where most people had 7+ years of experience so I was around people who had spent years shipping at massive scale, helped build foundational developer platforms, played critical roles at early stage companies, and for decades scaled the fundamental companies the economy runs on. Their experience showed up quickly in all of the architecture discussions and reviews. Simply hearing the war stories from all these different companies and all their experiences that shape what Brain Co.'s engineering culture is today was fascinating too. The team gave me room to keep following up on each problem. Along with this mentorship and the code reviews, the team made it possible for an intern to carry every piece of this into production.

I had frequent one-on-ones with my mentor, of which several were informal sessions where we went to get a coffee or walk around the pier and the beautiful surrounding neighborhood (the Brain Co. office is near Oracle Park and South Park). We would occasionally have a few recurring meetings with the broader team, a skip-level meeting every few weeks with leadership, and constant technical discussion in Slack.

Since my team built the tools for the whole company, every engineer in the company is a potential user, and as such, as an intern, I had the ability to work directly with leadership, which was exciting at a fast-growing company like this. I could announce my launches in #engineering, and I could see my work recognized in #props. That gave me far more visibility than I expected as an intern, which made me proud of my work.

The team likes working and hanging out together. We had daily lunches in office, where we talked about things we did over the weekend or things we enjoy outside of work and we also had frequent team dinners at places around SF. Every Thursday, we had a cooler that was stocked with beverages for our Bev Minute, when we had randomly selected engineers from all throughout the company speak a minute about anything they want. In some weeks, I talked about what I was doing at work so that the broader company had context. Some weeks, I talked about my New York trip or my near 30-mile hike at Yosemite.

The company and the broader Platform organization itself grew quickly during the summer, and seeing the company grow heightened the feeling of being in a rocket ship startup.

What's next

I arrived with experience in AI products from my previous internships and a personal interest in systems from the research I do in university. Now I’m leaving having spent the whole summer learning production infrastructure, cloud networking, billing systems, and security constraints of regulated deployments. Several of these things were new to me, and Brain Co. is fast-paced with broad ownership over what you touch. I spent more than a few evenings watching infrastructure talks to catch up on vocabulary I didn't have yet. My team members themselves were always willing to slow down and explain things almost like we were in a classroom at times. These were some of the most exciting days because my learning trajectory was steep at Brain Co.

I'm heading back to UCLA for my junior year. Three months ago, I joined hoping to learn some infrastructure and test the vibes of an early-stage, growing startup that I had conviction in. Since then, I've built and shipped their LLM inference usage metering attribution platform, carried it through a production cutover, integrated billing data with no standard APIs, and resolved a deployment loop in infrastructure.