DEV Community: Priyanshu Singh

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

Priyanshu Singh — Tue, 03 Nov 2026 04:16:05 +0000

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.

Push. A GitHub App receives the webhook. We verify the raw HMAC-SHA256 signature before anything else.
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.
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.
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.
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.

Follow the Money: Building a Graph-Based AML Investigator with FalkorDB

Priyanshu Singh — Sun, 18 Oct 2026 18:18:20 +0000

Tripwire: a fraud investigator that walks the money trail in FalkorDB. Built for Graph Hacks (WeMakeDevs × FalkorDB), Track 1: Agents That Act on Connected Data.

On day two, our investigator took 3.5 seconds per case. That was annoying. Then we found out it was also wrong. For our demo transaction, hi8-tx-03863669, it said the sender had 2 counterparties and no fan-out. The real answer was 7 counterparties and 7 fan-out matches. One Cypher quirk had quietly cut the investigation window short.

This post covers how we built an agent that follows money through a five-million-transaction graph, the query bugs that made it slow and wrong, and the evaluation trap that almost gave us a headline number we'd have had to walk back.

Code: https://github.com/PriyanshuSingh9/tripwire

A score tells you where to look

A fraud model scores one row: an amount, two accounts, a timestamp. Laundering doesn't live in one row. It lives in what happens next: the receiver forwards almost the same amount an hour later, then the next account does it again.

Fig 1. One row and one score, versus the same transaction traced: 65 paths, 15 transactions, 17 counterparty records.

Tripwire splits the work up. LightGBM ranks transactions. When one is worth a look, an investigator walks the graph in FalkorDB and writes a report where every claim links to a transfer you can check. The design comes from Coinbase's write-up on their fraud agent: a bounded LLM reviewer that sits behind the ML and the rules, not in place of them. We wanted to see how far that idea goes when the reviewer gets a graph instead of a flat history.

The graph, and the rule we didn't break

The data is IBM's synthetic AMLworld HI-Small set: 5,078,345 transactions over 18 days, with 5,177 labelled as laundering (fan-outs, fan-ins, cycles, layering).

The rule: a feature can only use what was knowable before the transaction happened. That means a frozen chronological split, same-minute groups kept in one split, half-open windows [t - w, t), and labels kept out of the graph, the features and the API. The rule paid off. Partway through, we caught our first feature file still carrying the label column, one careless join away from a fake result. Now features are built from an explicit allowlist, and labels are joined only inside the trainer.

We started with (:Account)-[:TRANSFER]->(:Account), then promoted every transfer to its own node:

(:Account)-[:SENT]->(:Transaction)-[:RECEIVED]->(:Account)

. Every transfer is a node the agent can cite. Labels never enter the graph._

The investigator's job is to cite transfers, so each one needs a stable ID (hi8-tx-{row}). A path it returns is then a list of real records, not something inferred from edges. CALL db.propertyKeys() on the loaded graph shows no label property at all, so nothing, the agent included, can peek.

Three tools, zero generated Cypher

The agent never writes a query. It picks from three parameterised tools:

trace_funds follows money upstream or downstream, 1 to 3 hops, inside a time window.
inspect_counterparties shows who's on each side and what else they've been doing.
detect_flow_patterns checks for fan-out, fan-in and pass-through.

Every tool has hard limits (depth 1–3, a window of 30 days at most, 100 results at most, a 5 s timeout), and every result comes back with transaction IDs, amounts, the path and query_duration_ms. This is the outgoing depth-2 branch of trace_funds:

MATCH (anchor:Transaction {transaction_id: $transaction_id})
WITH anchor, anchor.timestamp_epoch - $time_window_seconds AS lo,
     anchor.timestamp_epoch + $time_window_seconds AS hi
MATCH (anchor)-[:RECEIVED]->(a0)-[:SENT]->(t1)-[:RECEIVED]->(a1)-[:SENT]->(t2)-[:RECEIVED]->(a2)
WHERE t1.timestamp_epoch >= lo AND t1.timestamp_epoch <= hi
  AND t2.timestamp_epoch >= lo AND t2.timestamp_epoch <= hi
RETURN anchor.transaction_id, t1.transaction_id, t1.amount_paid,
       t2.transaction_id, t2.amount_paid, a0.account_key, a1.account_key, a2.account_key
LIMIT $result_limit

At depth 1, the demo case returns 15 transfers, all one hop away: payments into the anchor's sender (its receiver sent nothing onward inside the window). At depth 2 the same bounded call returns 65 paths through the same 15 transactions: 15 one-hop records plus 50 two-hop chains that link them through the sender account, every record keeping its own ID and amount.

Without a graph, that's a self-join on a five-million-row table for every hop. In FalkorDB, it's one pattern.

The LLM never gets the last word

LightGBM scores. A deterministic policy turns the score into allow or review. The LLM can't change either one.
The investigator picks the tools and drafts the report. Gemini is opt-in, and the default report is deterministic.
A verifier checks every ID, path, amount and date in the report against what the tools actually returned. Anything that doesn't match gets dropped.

. The LLM chooses graph tools and writes. It never scores, and it never gets the last word._

Because of that, the agent can say no. On a quiet transaction from the same slice, hi8-tx-03988788, the deterministic investigation returns outcome: no_matching_path: zero paths, seven related transfers on record, and no attempt to dress the empty result up as safety. The workbench spells it out: "The graph was queried and nothing matched within these bounds. This is not evidence that the transaction is safe." For a compliance tool, a refusal like that matters as much as a catch.

The same three tools are exposed over MCP: api.mcp_graph serves them as typed, bounded MCP tools that delegate to the same parameterised queries, the agent calls them through an in-process MCP client session by default (direct transport is one config flag away), and the same server runs over stdio for external clients.

The day `fan_in` took 891 ms

On a one-million-transaction slice, one investigation (five tool calls) took about 3.5 s. Even an account with five transfers spent around a second finding zero matches. We found four causes:

The planner picked the wrong index. For account-anchored queries, our range index on timestamp_epoch made the planner scan every transaction in the window (528,982 rows for one day) before filtering down to the account. We dropped that index and bound the indexed anchor with WITH before expanding. Now cost grows with the account's degree, not with the size of the graph.
UNION ... ORDER BY ... LIMIT only applies to the last branch. Our "latest activity" lookup returned the wrong epoch for 497 of the 500 accounts in our equivalence fixture. That's the bug that ended windows early and turned 7 counterparties into 2. It also let a 3-hop trace with LIMIT 50 return 3,404 paths.
Pass-through built a cross product of every incoming and outgoing leg before limiting. Now it builds a histogram of outgoing timestamps first.
Pointless second hops went out just to read a key the transaction node already had.

Fig 4. Dropping one index took a zero-match query from about 1 s to about 3 ms.

We froze the old queries and wrote equivalence tests before touching anything, then re-measured on the same slice:

Fig 5. Same real slice, same case, P50 latency on a log scale.

Then we loaded all 5,078,345 transactions: 521 s to load, every count reconciled, 2.5 GB of graph memory (we'd projected about 7 GiB from a sample). The demo case now investigates in 23.2 ms P50, and hub accounts with up to 169,756 connections take 207 ms P95.

Fig 6. Measured beats projected. Serial, single client, shared dev machine.

Did the graph help the model? Yes, with a twist

On the frozen test set (761,639 rows), all three candidate models were committed before any of them saw test data, and each was scored on test once. The selected model reached 0.753 average precision and caught 47.7% of laundering in the top 0.1% of alerts, up from 15.9% for the baseline.

Fig 7. One easy tail inflates the headline. The Sept 9-10 bulk number is the one to trust.

Here's the twist. The last 1,108 test rows are 59% laundering, and every model finds them easily. That tail holds 42% of all test positives. The fair comparison is the Sept 9–10 bulk, where AP goes from 0.088 to 0.600, close to the 0.609 we saw on validation. We report both numbers.

There was a second trap too. In our first iteration, graph features made AP worse (0.159 → 0.152). The cause turned out to be one overfit model, not the features. Across seeds on validation, the same graph columns helped every time.

One caveat on those headline numbers. Review caught afterwards that log_received_over_paid, one of the feature-family columns, compared raw amounts even when the paid and received legs were in different currencies. The guard is in place now: the ratio is null unless both legs share one currency and are strictly positive, and a separate currency_mismatch flag carries the mismatched case, with tests for mismatched, zero, and missing amounts. The 0.753 and 0.600 figures above were produced before that guard. Re-running the corrected candidate on the frozen test cohort means a new, ledgered test look, and that has not happened yet, so the numbers stay labelled pre-fix rather than quietly re-scored.

Where FalkorDB earned its place

Computing offline features through FalkorDB took 1,563 s for 5 columns. DuckDB does 76 features in 177 s, and its graph columns match on all 5,078,345 rows. So batch features run as SQL, and FalkorDB answers the live, per-case questions: where did this money go, who's around it, does it look like a fan-in. Those answer in milliseconds, as a path you can show a person.

Fig 8. Scan with SQL. Walk outward from one entity with the graph.

FalkorDB features we leaned on: parameterised Cypher; range indexes on account_key and transaction_id (and learning when dropping one makes the planner better); db.propertyKeys() as a leakage check; client-side timeout= on graph.query; GRAPH.MEMORY USAGE and INFO memory for capacity; and the FalkorDB Browser on localhost:3001 for eyeballing paths. No algo.* procedures made the cut.

What I'd tell myself on day one

Use the graph for questions that start at one entity and walk outward, not for scans. Index the wrong property and the planner turns the first kind into the second.
Measure on real data early. Our 7 GiB projection and our 3.5 s investigation were both wrong.
Freeze old queries before optimising. A faster answer that's different is a bug.
Check where your positives sit in time.
Make the LLM optional and the verifier mandatory.

TL;DR

Tripwire scores synthetic transactions with LightGBM, then investigates the risky ones by walking a five-million-transaction FalkorDB graph through three bounded tools. Every claim in its reports is checked against real transfers. Query fixes took an investigation from 3.5 s to about 25 ms and made it correct. On the hard part of the test set, past-only graph features lifted AP from 0.088 to 0.600. Synthetic data, research demo: it says nothing about real-world AML performance.

What would you want an investigator agent to refuse to claim?

Built by Kanishka (@Kaniisshka), Ashwani Jha (@Ashwanijha1405), Parth Garg (@Parth06102006), and Priyanshu Singh (@PriyanshuSingh9). The graph model, queries, evaluation protocol and decisions are ours, and we can explain every one.