Gerson

Inspiration

One of our first interviews was with an analyst who had spent an afternoon building a tool that pulled his weekly numbers and drafted the summary. It worked. A colleague doing the same job in another office had never heard of it.

That story repeated across twelve companies. AI has made it possible for people who have never written production code to build software for their own jobs. What has not changed is where that software goes. It stays on one laptop until that person changes teams.

A mentor conversation on day three gave us the frame that made the idea land. Every large company documents how work gets done, and what employees are automating is almost always one of those standard operating procedures. Once we described Gerson that way, people stopped asking us to explain it.

What it does

Gerson is a secure centralized library of small software that optimizes a company's SOPs. An employee publishes what they built, shares it with one person or the whole company, and anyone else can find it by describing the task in plain language and run it in the browser.

The reason this cannot just live on AWS is that existing cloud infrastructure assumes an engineer, a security review, and a budget code. Every company has a cloud for the software it sells. None has one for the software its employees build.

How we built it

Every tool carries a tool.yaml manifest at the root of its repo. The manifest declares how to run the tool, a Dockerfile and a command, along with its inputs and outputs, the resources it needs, whether it touches company data, and who it can be shared with. That one file is what lets Gerson take someone else's code and hand a non-technical colleague a form with two file pickers and a Run button.

Publishing takes a public GitHub link. Gerson reads the manifest, validates it, and previews exactly what other employees will see before anything goes live.

Discovery runs through chat instead of a search box. The assistant reads the manifests, reasons about which tools fit the described task, and returns ranked matches with the owning team, sharing scope, run count, and language. Follow-up questions narrow the results. When the model is unreachable it falls back to ranked catalog matches and says so.

Running happens in a container per tool. Output comes back as a readable table with an Excel export, and the dashboard tracks every run against what the same container would cost left running for a month on Fargate or Azure.

Challenges we ran into

We started by calling it a marketplace. An advisor stopped us on that immediately, since nothing here is bought or sold, and we moved to library.

The hardest open question is not technical. Deciding who can publish, what triggers a security review, and how that review avoids becoming the bottleneck that sends people back to downloading tools off the internet is the real design problem. We modeled tiered sharing in the manifest as a first answer.

Publishing also still assumes a repo and a manifest, which is the right path for a developer and the wrong one for the marketing SVP we keep describing.

Six of us met days before the hackathon started. Splitting by function early, and being willing to throw out a day of positioning when a mentor showed us a better frame, mattered more than any single piece of execution.

Accomplishments that we're proud of

We shipped the whole loop, not a slice of it. Publish, share, discover, run, and account for the cost all work end to end.

We wrote example tools in Python, Java, and Go to prove the manifest is language-agnostic, so Gerson is not tied to whatever stack the first team happens to use.

We ran 20 interviews at 12 companies in four days, from analysts to SVPs, and built the product against what they told us rather than what we assumed.

The cost accounting is real and sourced. Three runs totaling 0.88 seconds cost twelve millionths of a dollar against thirty six dollars for an always-on container, priced off published Fargate and Azure Container Instances rates.

What we learned

Two findings shaped the product. 15 of 20 people we interviewed had automated a task their company formally documents as a procedure, which told us this is structural rather than occasional. 8 of the 17 who had built something were asked by a colleague for access, which told us the demand to share already exists with nothing to meet it.

The bigger lesson was about positioning. The product barely changed between Friday and Sunday. The way we explained it changed completely, and that was the difference between polite nodding and people finishing our sentences.

What's next for Gerson

Connect the MCP layer. The runtime already exposes tools in a form a model can call. Wiring that up lets an employee's AI assistant reach into the company library directly, instead of the employee going to the library first.

Publishing without a repo. The next version needs to accept a folder or a single file and generate the manifest, so the people we built this for can actually publish.

A real review queue. Tiered sharing is modeled in the manifest today. Turning it into an IT review workflow with an audit trail is what makes Gerson deployable inside a regulated company.

A pilot. Free for four weeks with one team, to measure how many tools get published and how many get reused by someone other than the person who built them.