From agentic development to agentic deployment: building Summit at hackCBS 9.0

This is a submission for the MLH x DEV Writing Challenge

What I Built

TL;DR: Summit is a Railway-style PaaS. You push code, and it builds and deploys your app on Kubernetes. It also runs AI agents as real workloads next to that app. Agents now write our code. We wanted them to deploy it and keep running after it ships.

Why

Coding agents changed how we write software. Our team wrote most of Summit with AI coding agents: we wrote the spec, the agent opened the PR, and we reviewed it. That part is agentic development, and it already works.

Deployment hasn't caught up. Most platforms still treat an agent as an API call your app makes. Nothing keeps its state if the process dies. Nothing isolates the code it runs. Nothing tracks what it costs per user.

So we built for the second half: agentic deployment. A PaaS where a git push ships your app and your agents together, and those agents are durable, sandboxed and owned by a user and a project.

How the deploy path works

Summit is a pnpm + Turborepo monorepo: a Go control plane, a Next.js dashboard and an OpenAPI 3.1 contract shared between them.

1. Push. A GitHub App receives the webhook. We verify the raw HMAC-SHA256 signature before anything else.
2. Record the intent. The Go API writes the deployment and an outbox_events row in the same Postgres transaction. Either both exist or neither does.
3. Dispatch. The orchestrator claims outbox rows with FOR UPDATE SKIP LOCKED. If it crashes mid-job, the row is still there and another worker picks it up.
4. Build. Each build attempt gets its own pod in a gVisor (runsc) sandbox. Railpack detects the language and writes a build plan, and rootless BuildKit turns it into an OCI image pushed by digest. Customer code never touches the host kernel.
5. Run. The reconciler turns intent into Kubernetes resources in a per-user namespace. Traefik gives it a public URL, Cilium enforces network policy, and a managed Postgres addon is one click away.

The outbox was the best decision we made. Every async step goes through it, so "the server restarted" never means "your deploy vanished."

How managed agents work

This is the part I'm proudest of. An agent on Summit is a resource like a service: you create a definition, cut an immutable revision, deploy it to an environment and open sessions against it.

Under the hood:

• Go stays the source of truth. Agents, revisions, deployments, sessions and runs live in Postgres, scoped to user_id and project_id. Every create takes an Idempotency-Key. Replay the same request and you get the same resource; change the body and you get a 409.
• One Rivet Actor per session. The orchestrator hands agent.run.submit events to a small TypeScript adapter. The adapter finds or creates the session's actor, keyed by ["summit-agent-v1", project_id, deployment_id, session_id]. Keys are generated server-side, never by the client.
• Pi Durable runs inside the actor. Each actor owns exactly one Pi Durable conversation. We wrote a typed adapter so Pi stores its transcript and request IDs in the actor's own SQLite database (c.db) instead of local files. Pi's full storage conformance suite passes on it: 25 of 25 cases.
• State survives. When an actor sleeps and wakes, it reopens the harness and recovers the whole conversation, plus its idempotency state. Delete a session and Rivet destroys that one actor and its storage. Other sessions don't notice.

We first tried one actor per deployment holding many conversations. It failed on a real constraint: Pi Durable 1.4.0 has no API to delete a single conversation, so purging one user's session would have meant raw SQL against Pi's internal tables. One actor per session made deletion clean, so we switched.

The next milestone is the execution boundary. Agent tools will run in a fresh gVisor sandbox per run attempt, with default-deny networking, and model calls will go through a gateway that hands out scoped credentials, so no raw provider key ever reaches an actor.

What I learned

• Write the contract first. We kept the OpenAPI file as the source of truth. With four people and a lot of agent-written code, that file stopped most integration fights before they started.
• Agents need specs, not prompts. Our agents did their best work from tight docs: an AGENTS.md, ADRs and small tickets. Vague asks got vague code.
• Durability is a design choice. The outbox and the actor-per-session model both came from asking "what happens if this dies right now?"

Partner Technologies

GitHub. The GitHub App is the front door to Summit. We built the full flow in Go: an RS256 JWT for the app, cached installation tokens, raw HMAC webhook verification and a normalizer that turns push events into deploy intents. A worker credential broker gives each build a short-lived token scoped to its repo, so build pods never hold the app's private key. Repos, installations and deploy sources each have their own API handlers and their own tests.

DigitalOcean. We were in the DigitalOcean track. Summit's fleet runs on DigitalOcean Droplets. Plain VMs meant we could set each machine up the way a PaaS needs, down to the gVisor runtime that our build sandboxes depend on.

Google Gemini. Gemini was our main coding agent. We used it to turn specs and tickets into PRs across the Go backend and the TypeScript adapter. It worked best with small, well-scoped tickets and a repo-level AGENTS.md that described our conventions.

Hackathon Experience

We built Summit at hackCBS 9.0 in Delhi as a team of four: Deepanshu, Rudra, Arpit and me. We split it the way the system splits. Deepanshu took the frontend, Arpit the platform database, Rudra the Kubernetes orchestrator, and I took the Go API, the builder and the agents.

The event ran for 36 hours, and the management was really smooth. At any moment there were at least two people around to help us, and they sorted out whatever we needed on the spot. That let us spend the whole time on the hack itself.

Summit is open source: github.com/Deepanshu-2006/Summit. If you've tried running agents in production, I'd love to hear what broke first.