Projects

Any recipe is now a search away, and an AI will write you a new one in seconds. What a home kitchen still lacks is a companion: something that knows what your family likes, gets you through the cook with wet hands, and remembers how you made it last time. Most cooking apps answer with more scrolling, more pop-ups, and more screens to manage.

Sous is my attempt at the opposite: the ultimate home cook companion, and a calm one.

The prototype on our counter

The prototype is a working app running on a Pixel Tablet sitting on our kitchen counter. Recipes come in by message: I send one to our kitchen agent, and it lands in the app's queue alongside our family's own recipe book. Before we start, Sous turns each recipe into a cook plan. It splits prep from cooking, pulls out anything that has to happen ahead of time, and lays out which steps run in parallel.

This project is testing out a light non-consensus thesis I have: that in a multi-agent future, we'll all want an agent dedicated 100% to understanding 'us' and injecting that into every workflow with other agents.

Other agents will specialize in tasks, verticals, projects, types of work, etc. based on their harness and training. And they'll have access to our preferences, memory, data, etc. in many cases. But the thing that differentiates 'me' from anyone else, more than anything else, isn't actually captured well in those discrete files -- it's the taste, judgement, patterns and nuanced day to day things that can only be inferred from a large amount of experience and is best captured in weights, not in files.

This project experiments on that thesis that taste should live in one deep node that other agents consult, the way you'd ask the colleague whose judgment you trust rather than hand everyone a style guide. It started as a note to myself: "make a model that is purely embodying my taste - find right tech or way to encode this (maybe not text) and store it. Use as a way to learn a level deeper. And make a partner everywhere."

I didn't start with a model right off the bat. For now it's a thin agent storing a record of my judgments: what I approved, what I changed, what I rejected, and why. It manages, updates, prunes and accesses that record and interfaces with other agents in my workflows to see if having that dedicated expertise improves outcomes and alignment to 'my taste.'

As COO, I led go-to-market, product strategy and operations through the company's merger and its pivot to an open evals network for AI, which we ran as an AI-native operating experiment.

For six days, the job that syncs my messaging threads reported "ok" every 30 minutes while syncing nothing. The messaging service had started rejecting the old client at the handshake, and the sync tool exited cleanly on total failure. It logged 285 runs, every one "ok" and every one a failure. I found it by luck, during a routine upgrade.

The job belongs to my OpenClaw agent. OpenClaw is an open-source agent you host yourself, and mine runs on a small cloud machine around the clock. I talk to it on Telegram, and it's locked to my account. It runs on Claude, with access to my email, read-only access to my messaging threads, and a notes repository it commits to on its own. A dozen or so scheduled jobs do the routine work: watching for deadlines, tracking returns, syncing messages. Our kitchen agent lives there too. It sends recipes to Sous, our cooking app, and keeps our family recipe book.

That failure was typical. An always-on agent is an operations problem before it's an AI problem. The model was rarely what broke. The plumbing broke, and it broke quietly. Earlier in the summer, a missing flag made the same sync hang the agent's half-hourly check-in, and after that the sync quietly stopped running. Nothing came in for a month, and when I fixed it, 14,902 messages arrived at once. The check-ins had a failure of their own. Over a month and roughly 1,500 of them, the agent replied that everything was fine and never once ran the checklist it was meant to run.

Some failures were worse than silence. The returns tracker once warned me about a deadline on an order number that didn't exist anywhere in my email. The model had made it up. The rebuild changed one rule: nothing gets written unless it can point to the source message it came from.

Each capability in Daclaude is a plain-text `SKILL.md` file — the prompt is the codebase, an Obsidian vault is the persistent state, and ~30 skills handle email triage, voice capture, quests, medical reimbursements, and financial modeling. On a morning walk I can send a voice memo on Telegram; the bridge transcribes it, classifies it against a routing map (`ROUTING.md`), and files anything above 90% confidence straight into my rolling journal, a project folder, or my task list without me opening a laptop. When a skill falls short, I edit its markdown instructions mid-session: `/handoff` captures what broke, an adversarial verifier checks the fix, and learnings compound across sessions.

For a while, the system's biggest problem was that it wrote me too much. By September there were five bot-authored documents in my inbox every week: a content digest, an attention list, a deadline watch, a weekly review, and a weekly journal template. Each made sense when I added it; together they competed for the same few minutes, and some I wasn't opening at all. The weekly review proposed email filters for me to approve by ticking a box — in five weeks I ticked zero, and its list grew to twelve items nobody read.

Getting it right was mostly deleting. A daily prep note and a weekly recap went in June; a health table, a handwriting-to-journal pipeline, and a reading-review queue followed. What survived are two quiet documents: a Reads Issue on Tuesday and Thursday mornings — newsletters, feeds, and bookmarks synthesized into a single twenty-minute sit-down read — and a Weekly Digest on Fridays centered on one rule in the system's own instructions: orientation is presence, not productivity. There are no activity logs or streaks to keep; the opening prompt simply asks, "what do i WANT to do this week? and why?"

The issues are also how I talk back to the system. Any inline reply I leave under an item gets processed on a twice-daily pass and receipted in place. If I write `"do it"` under an item — with an instruction or without one — a background Claude session spins up on its own branch, does the work, and stops at ready-for-review. Anything urgent enough to surface outside that rhythm gets a single line at the top of my notes home page, and deleting the line dismisses it.

A project for learning to build a machine-learning pipeline end to end, and then to tell whether the model it produced was worth anything. The model predicted funding rates: the periodic payment one side of a perpetual futures contract pays the other, which a hedged strategy can collect. An earlier phase, funding-rate-arb-backtesting, had built the backtester and found a simple baseline nothing beat: pick the best-paying venue and hold.

The pipeline covered the whole path. A 323K-row dataset across six trading venues and 20 assets, 46 engineered features, a LightGBM model that forecast a range rather than a single number so each prediction carried its own uncertainty, train, validation and holdout splits by date so the model never saw the future, and a live FastAPI + Vercel cron job serving predictions.

On paper it was excellent: 86% accuracy calling the direction of the next rate, 93% on the best venue. But that venue pays positive about 93% of the time anyway, so always guessing "positive" would have scored about the same. Past rates made up two-thirds of what the model leaned on. Its confidence scores were broken too, stuck between 0.05 and 0.11 whatever its accuracy, so the position sizer (Kelly, which bets more when confidence is high) churned 79 trades and lost more than its starting capital in a leveraged backtest.

The pipeline itself was quietly wrong in three places. The default prediction source was a mock, not the trained model. Rates were summed where they should have been averaged, inflating predictions three to ten times. And the filter meant to block low-confidence trades was switched off. None of it threw an error. Each bug just produced a plausible number. I fixed all three and added 32 tests to keep them fixed.

A surprising share of recurring founder work — pressure-testing a plan, triaging an inbox, coaching yourself through a hard call, sharpening a prompt — fits into plain-markdown instruction files that Claude Code loads on demand. I wrote these for my own daily work running a startup and open-sourced the set for other operators; the radical-candor coaching skill alone replaced hours of solo "let me think through this" time.

At Recall the same pattern became a shared team repository (`recall-skills`): `/commit` for structured commits with a short reflection, and `/learn` for routing what a session discovered to the right docs, so what one person's agent learned reached everyone's. I also used the suite as the base for Operator Superpowers, an experiment in whether a five-agent AI executive team (a CEO plus marketing, sales, content and ops) could run a small real business while the founder focused on product.

Atlas started as a way for our team at Recall to ask questions about company context without digging through docs and chat. By December it was doing the reverse: comparing each day's commits, threads, and docs against our stated plans and telling us when our daily work had quietly drifted away from our own strategy.

The first version in August 2025 was a small MCP server. It pulled daily activity from docs, project tracking, code, and chat into a daily summary, and served it from one backend behind both desktop coding agents and a team chat bot. Anyone asking a question in chat and an engineer working in their editor were querying the same memory. Alongside company knowledge and daily summaries, we shipped early content tools to draft social posts and blog pieces in the company voice.

September 2025: Semantic search and chaining

A month in, daily summaries and keyword lookup weren't enough once history accumulated. We added `pgvector` semantic retrieval across all company knowledge and past summaries, alongside live web research, social and blog RSS monitoring, partnership research, and PR review context.

A decentralized data network where applications build on shared, user-controlled data streams. It replaced the 3Box.js approach with event-sourced streams anchored to verifiable timestamps, IPFS for content-addressed storage and a custom consensus mechanism for ordering.

As CEO of 3Box Labs, I led the company through Ceramic's whole life: protocol design, network launch, the developer ecosystem and, in 2022, ComposeDB, a GraphQL interface that made it usable for ordinary web developers. Hundreds of applications were built on it. Mainnet launched in 2021, and Ceramic worked with IPFS, Filecoin and The Graph.

The idea I'd point to is composable data models: shared schemas that let different applications read and write the same data without coordinating with each other.

An open-source JavaScript SDK that let decentralized applications store user-controlled data and identity profiles. Instead of every app building its own user system, 3Box.js was a shared layer where people owned their information and could carry it between apps.

More than 100 early projects adopted it, among them Uniswap, Gitcoin and Aragon. It covered encrypted private data, public profiles, messaging threads and sharing across apps, all tied to a user's cryptographic account and stored on IPFS and OrbitDB, not a central server.

It proved people wanted this, and it showed where IPFS fell short for production: performance, reliability and queries all needed a rethink. That rethink became Ceramic.

The core problem wasn't gamifying arithmetic — it was mapping the new Common Core fluency standards into a progression that made mathematical sense instead of reading like a checklist. As PM at Zearn, I led the creation of proprietary curriculum IP around how the standards built on one another: which concepts were true prerequisites, where common student misconceptions lived, and how to sequence interactive visual models so kids built genuine number sense rather than memorizing procedures.

Number Gym became the first product suite to implement the new standards end to end, reaching millions of elementary students across the US through Zearn's school and district partnerships.

As Zearn's first PM, I owned Bubbles — our first iOS app — alongside Number Gym, two of the company's four early product lines. Each round adapted to where the student was: facts a kid missed came back on a spaced-repetition schedule, while mastered tables stepped out of the way so practice felt like a game rather than a drill. We tested the prototype directly with elementary classrooms in NYC public schools to tune the pacing and difficulty curve.