/ home directory / california /

Aditya Kolekar.

Computer Science/AI. Building software that shows its work.

What I built in summer 2026

A field log of six projects, from a phone-side agent server to tools for civic search, advisors, customer retention, publishing, and branching conversations.

I spent this summer moving between products with very different users. An AI agent asking to use a phone, an administrator looking for a volunteer record, an advisor reviewing a document, and a café owner deciding whether to contact a regular all need different interfaces. They do share one requirement: the system has to show its work.

Here is the short version of what I built and what each project made me think about. The linked project pages go into the engineering details and current status.

Porto: permission belongs on the phone

With Blue Orchid Society, I co-developed Porto, an iOS-first app that presents a phone as an MCP server. A remote agent can request a bounded device capability through a relay, but the phone decides whether the request is allowed. I worked across the React Native app, the relay and delivery path, a Swift macOS companion, and an OpenClaw integration.

The surprising amount of work was in what happens around the happy path: a connection drops, a queued request returns, a token rotates, or a person revokes access. The iOS release candidate is still being verified on signed devices, so I treat it as a system under test rather than a broadly available app.

SACDEMS: search has an access policy

At the Democratic Party of Sacramento County, I built an admin workspace that brings forms, people records, and official organization sources into one search flow. Natural-language queries are useful here, but they cannot be allowed to expand a user's permissions. The application checks roles and runs searches through scoped database functions; the AI planner selects only from allowed query shapes.

I also worked on reliable ingestion from Google Forms and a stateless Cloud Run deployment. Source links matter as much as answer text, because a useful answer should still let an administrator inspect where it came from.

Arvya: evidence before output

My Arvya internship crossed product engineering and go-to-market work. I built a social publishing agent with public-safe source context and editorial review, financial document workflows that produce cited artifacts, a source-backed signal pipeline over public filings, and advisor-facing deliverables and dashboards.

These were different pipelines, but I kept running into the same handoff: a system turns evidence into a claim, then the claim becomes something a person might publish, send, or use. I learned to make that handoff explicit. I can discuss the architecture, but the underlying client records and operational data stay private.

Churnary and Splay: a draft is not a decision

Churnary grew from a hackathon idea into a customer-retention product I am building with friends. It reads Square, Stripe, or CSV history, explains which regulars may be drifting, and prepares outreach for an owner to approve. I worked on the retention dashboard and workflows, pricing research, and the path from an interesting signal to a concrete next action.

Splay, another team project, tackles a related problem in publishing. It gives generated posts a place to be compared, reviewed, scheduled, and measured. Working on its API, media path, and review flow reminded me that even a good generation model needs ordinary software discipline around state and failure.

Tangent: room for a side path

Tangent was my more exploratory personal prototype. It asks what a chat interface should do when one sentence leads to several questions. I built a local-first workspace with branches, context packets, a graph, editing, and snapshots. The committed version uses a mock model provider; the point of the prototype is the interaction model, not a claim of production readiness.

I liked having one project where the goal was to test an interface idea slowly. That work fed back into the others: if a user cannot see why a system reached a result, the next action becomes harder to trust.

The summer did not point me toward one narrow category of software. It made me more interested in systems that can explain their evidence, respect a person's authority, and keep working when the ordinary failure cases arrive.