About Ashray

I kept building products. They kept turning into infrastructure.

Voice interfaces, commerce systems, developer tools, and agent runtimes looked like different problems. Following each one far enough kept exposing the same missing layer underneath.

Read the storyWork with me

The thread

Handoff

Infrastructure

Product

Most of my projects begin with a handoff I am tired of doing by hand: copying context, polling a process, opening a dashboard, or reconciling two copies of state.I turn the handoff into infrastructure, then keep going until the infrastructure feels like a product.

The through-line is not a framework or even AI. It is the refusal to leave an important boundary vague.

If two systems need to agree, I want a contract.

If work can fail, I want a receipt.

If a person has to trust the result, I want the interface to tell them exactly what the system knows.

01 / How I got here

I followed the product down the stack.

I did not set out to specialize in agent infrastructure. I kept building products, and the products kept showing me the layer I needed next.

Starting point

I started by copying the code.

In 2023 I was a Python and Java developer learning web development with GPT-4 in a ChatGPT tab: generate TypeScript, copy it into my editor, run it, repeat. ChatGPT was not a model I was integrating into a product yet. It was how I crossed into a part of engineering I did not already know.

Once I could build for the web, I started shipping complete AI products: tool-calling chat interfaces, generative UI, image workflows, voice agents, dashboards, and the operational software around them. Years later, ChatGPT became a coding agent in my workflow again, except now it has a machine and a direct line to my local agents.

The turn

The products kept exposing the missing layer.

I learned the same lesson from very different products: the model is usually ten percent of the work. An image agent needs versioned artifacts. A voice assistant needs scoped tools and an honest latency budget. A calling product needs a durable lifecycle, not a fetch request. Commerce AI needs to call the same operations as the buttons instead of growing a second copy of the business logic.

Each product pulled my attention toward permissions, state, delivery, observability, and the operator on the other side of the screen. I kept moving deeper into the system because that was where the product kept breaking, and where the decisions that made it feel trustworthy actually lived.

Now

Eventually I built the place the agents live.

When coding agents became my daily way of working, I found myself acting as their router, process manager, context monitor, and merge strategy. I tried smaller tools first. They taught me that the problem was not one missing command; it was the absence of a place where parallel agents, their worktrees, their messages, and their long-running processes were visible together.

That became goldengoose, the desktop workspace I now open every morning. When its runtime lessons became too useful to leave trapped inside one app, I extracted them into Gooselake. I never stopped building products. I learned to follow the product all the way down, and then carry the systems work back up into what a person sees and feels.

02 / One practice

The product tells the system what matters.

The systems work and the product work are not two versions of my career. They keep correcting each other.

What products taught me

An invariant only matters if somebody can feel it.

A user does not care that the event transport is elegant. They care that the active session stays instant, the call status is honest, and the control they pressed does what it said. Product work tells me which properties deserve serious engineering.

What systems taught me

An interface stops being trustworthy when it guesses.

Runtime work taught me to expose receipts, ownership, recovery, and failure instead of papering over them. The interface becomes calmer when the system underneath it has one source of truth and tells the truth when something goes wrong.

I do not want to choose between the machine and the interface. The useful judgment lives where they constrain each other.

03 / How I make decisions

A few rules I actually use

None of these began as values for a bio. They are lessons I wrote down after watching the alternative fail in a real project.

04 / Working with me

I spend the ambiguity up front.

Give me a fuzzy product problem, access to the people who feel it, and enough ownership to follow it across the stack. I will probably spend longer than expected deciding what should be built. Once the shape is right, I move unusually fast.

The slow conversation at the beginning is what buys the autonomy later. I want the specification to have no surprises before anyone implements it. From there I use agents aggressively for research, execution, review, and testing, but no implementer gets to certify its own work. Compilers, tests, fresh reviewers, and somebody using the thing in a browser own that decision.

I am happiest owning a problem through its seams: the product behavior, the interface, the application model, the integration boundary, and the runtime underneath it. I leave behind the documents, tests, and operational surfaces that let the next person understand the system without needing me in the room.

Staff engineer

For teams that need technical direction across product, platform, and applied AI, especially when the real problem lives between layers.

Founding engineer

For turning an unresolved product idea into its architecture, interface, first production system, and the loops that keep it improving.

Select client work

For focused problems difficult enough to need both product judgment and systems depth, from an early prototype through the software around it.

Get in touch

If the model is the easy part, we should talk.

I am open to full-time staff and founding engineer roles, as well as a small amount of focused client work. Tell me what you are building, where it gets difficult, and why it matters.

Email meBook 30 minutes