Unify

I rejoined Unify, a Y Combinator company (W23), in January 2025 as a founding AI engineer, after the Ivy spin-out, and stayed until October 2026. I worked across the stack, from the Next.js web app and the backend to the agents' runtime and the harness around them.

Unify Interfaces

Unify Interfaces, launched in March 2025, was an observability and evaluation platform for LLM applications. Its SDK captured detailed traces of what an application did on each request, teams scored those traces with their own evaluations, and they explored the results in tables and dashboards they composed themselves.

I built the tables and dashboards they explored it through, in Next.js. The hard part was scale. The tables let users drag, pin, and hide whole groups of nested columns and grouped rows on the server, so each group loaded only when opened, and on the backend the SQL generated from users' filters was shaped so PostgreSQL planned it well for small projects and for projects with millions of logged rows alike.

Unify Teammates

By late 2025 Unify had moved from watching LLM applications to giving companies agents that did the work. Unify Teammates, launched in March 2026, were AI agents a company onboarded like a new hire, through calls, screenshares, and documents, and then worked with over Slack, Teams, email, and live calls.

I built much of the platform under them, from the knowledge they drew on to the apps they wrote and the tools they used, and the shell of the web app that kept chat, live activity, and calls running from page to page. I also deployed pilots for prospective clients and supported their teams directly.

Knowledge

I built the RAG pipeline through which teammates searched a company's documents and computed over its spreadsheets.

Rather than cutting files into fixed-size chunks of text, it parsed each document into a hierarchy that followed its own headings, from sections down to passages and sentences, with tables and images filed under their sections. An agent could land on a sentence, passage, table, or image and widen out to the passage, section, or document around it when it needed more context. Spreadsheets and document tables became typed tables the agent filtered, joined, and totalled in its own code instead of reading rows as text, and ingestion ran on workers that scaled with the queue and never marked a file done until every row was stored.

Generative UI

Teammates showed their work as small apps they wrote themselves. Asked for a view of overdue invoices, a teammate wrote a React app, called a canvas, on a component kit I authored, rendered it in a real browser to check its own work, and revised it from the screenshot.

Canvases could also act, for example by emailing a report to a list of colleagues, and a model wrote that code, so I designed the boundary that made it safe on customer data. Each canvas ran in a sandboxed frame with no network access, where it could name an action but never see what it did, and the server checked every input, asked the user to confirm anything irreversible, and ran each action exactly once.

Integrations and workflows

I built the integrations through which teammates worked inside a company's own apps, connected through OAuth or API keys.

They were designed around progressive disclosure: from inside the code it wrote, an agent searched for the app it needed, then for the tool, and loaded that tool's schema only when it was about to call it, so a company's many connected tools never crowded its context. Every call then passed through the permissions the user had set for that account, where each action was allowed, asked about first, or blocked, and an approval covered only the exact call it approved.

On top of this I built installable agent workflows, which switched on once a customer connected the apps they needed. A recurring task that had worked could then be distilled into Python that called a model only for its judgement steps, so later runs were cheaper, faster and consistent.

Redesigning the agent harness

In 2026 Unify wanted its agents to get cheaper and more reliable the more they ran, and I led a ground-up redesign of the open-source Unify agent harness, in which an agent carries out each request by writing and running Python.

The old harness was the first baseline, so I started by redesigning it from the ground up. The redesign left the agent with a single tool that ran code and made every other capability a Python object in a persistent sandbox, with help the agent read only when it needed it, so its context carried only what the task in hand required. It moved code the model wrote out of the agent's own process, where it could see access keys, into a sealed sandbox, kept the context lean with compaction as it grew, and ran follow-up work, such as reviewing a finished task, as a fork of the agent's conversation so it reused the prompt cache.

Memory and the agent mesh

I designed the new memory for two things: memoization, reusing work the agent had done before, and generalisation, transferring what it learned to new work.

Each task was saved as one commit in a git repository, and after it the agent wrote up what it had done as a Python function. A separate writer merged related experience into a library of functions and notes, and a function earned trust only by working in later tasks, never by being re-run, since a function that pays an invoice should not run twice to check it.

The agents behind it formed an agent mesh: the acting agent, the writer, a librarian that matched stored functions to new requests, and sub-agents in their own sandboxes, addressing each other directly on one global crash-safe, append-only message log.

Results

We measured the new harness, memory on, against Unify's old harness and against three published agents with their own memory: OpenClaw, Hermes Agent, and Prime Agent.

On Continual-ARC, a benchmark Unify was building on ARC-AGI to test continual learning, puzzles recur over a long stream of work and each has a budget spent on worked examples and wrong answers. The new harness solved more puzzles than the old one at every model reasoning effort, 73.5% against 62.5% at low effort, and used less of its budget. Against the published agents, with the same model and settings, it solved more puzzles at every effort and used less budget at medium and high effort; at low effort it used more than OpenClaw and Prime Agent, and it cost more per puzzle than Prime Agent.

On an internal benchmark of office work I specified, a simulated finance team whose unwritten rules changed over time, it made 12 to 21 times fewer harmful mistakes, such as wrong payments, than Prime Agent. Across the designs, most of memory's benefit came from memoization rather than generalisation, which is part of why I now think much of what an agent learns belongs in its weights.