Inspiration

Every year, more than 600,000 people walk out of American prisons. Within a few years, two out of three are arrested again. It's easy to assume that's because they don't want to work. The opposite is true: most are actively looking for a job from the first week. The doors are simply closed to them.

We kept circling one fact that didn't add up. The help these people need already exists. Hundreds of programs offer exactly what's missing: help replacing an ID, job training that welcomes people with records, legal aid, transitional housing, food benefits. It is real, and it is funded. But it sits scattered across hundreds of separate organizations that can't see each other. The housing program doesn't know about the job training across town. The job training doesn't know about the legal clinic that could clear someone's record. So a person leaving prison stands on the curb holding a plastic bag and a debit card with less than two hundred dollars, needing a state ID to get a job, an address to get the ID, and a job to get the address. Everything they need depends on something else they can't get yet. The problem was never a shortage of help. It was that the help was invisible, and arriving in the wrong order.

The name comes from literature. Alyosha is the youngest brother in Dostoevsky's The Brothers Karamazov, the one who meets people at their lowest and still believes they are worth more than their worst moment. That idea became the ethic of the whole project, and we kept one line pinned above everything we built: each of us is more than the worst thing we've ever done. A returning citizen, the term for someone rebuilding an ordinary life after prison, deserves a tool that treats them that way.

What it does

Alyosha is one platform that connects the three groups who can't see each other today: the person coming home, the organizations offering help, and the caseworkers, the staff at reentry nonprofits whose whole job is guiding people through this, who move people between them.

For the returning citizen, it's a map. Their steps appear in the order that actually works, ID first, because the job, the bank account, and the lease all ask for it, each one in plain words: what to do, where to go, what to bring.

Steps stay locked until the one before them is done, so they're never staring at a dozen tasks at once. When they have a question at midnight, they can ask Alyosha's AI companion, which answers only from documents we verified by hand and shows its sources so they can check. When a question is too important for software, like a legal decision or the terms of someone's parole, it doesn't guess. It points them to a real person.

For the caseworker, Alyosha reads their intake notes, the first interview where they learn a new client's situation, and drafts a full profile and step plan in seconds instead of days. They review it, fix what's wrong, and approve it. The final judgment stays with them. Two further tools, Caseload Intelligence and Gap Analysis, watch the state of people re-entrying and flags which one need immediate assistant and compare what clients need against what the network actually offers. Between the two sides sits one shared network, so every organization that joins makes the picture more complete for every client and every other organization.

How we built it

We're a small student team, and we built Alyosha as a single Next.js codebase with two deliberately different faces sharing one database, so the two sides are genuinely connected: a caseworker approves a plan and the client sees the map; the client checks off a step and the caseworker's dashboard reflects it.

The application is built on Next.js with TypeScript and Tailwind, one repository split into two surfaces by route groups. The client side is designed for low digital literacy: large type, one action per screen, plain language, big tap targets, and a read-aloud button on every page. Supabase, running Postgres with the pgvector extension, holds both the application data and the AI's document library in one place, so we never needed a separate vector database; the same Postgres stores our verified documents as searchable meaning-vectors. We use OpenAI for the language work, a stronger model for the caseworker's reasoning features and a faster, cheaper one for the chat, and we deployed the whole thing live on Vercel.

The AI is grounded, not freewheeling. The chat uses a method called retrieval-augmented generation, which simply means the AI may only answer from documents we hand it, never from its own memory. When someone asks a question, we turn it into a vector, find the closest passages in our verified library, and hand only those to the model with a strict instruction to answer from the sources and cite them. We built the corpus, our vetted library of source documents, one file at a time from official New York City and State pages and established nonprofits, recording the source and date on each, and we gated the system so it physically refuses to load any document a human hasn't marked verified. We set New York City as a deliberate testbed so we could go deep and check every source by hand rather than scrape a shallow national list.

Every AI feature returns strict, validated output and falls back to a safe pre-written response if the model is unreachable, so the demo never fails in front of a vulnerable person. And on the part that matters most, the order in which someone rebuilds a life, we used no AI at all. That sequence follows plain, fixed rules, on purpose, because some things are too important to leave to a guess.

Challenges we ran into

The hardest lesson came from our own AI. Early on, one of our first four source documents, the one covering the law that protects people with records from being rejected for a job, couldn't be fetched cleanly because the government page blocked our tool, so it got reconstructed from secondhand summaries. That is exactly the failure we were building the whole product to prevent: a confident-looking source that nobody had actually verified. We caught it, re-fetched a clean authoritative version, cross-checked every specific against multiple sources, and then went further by re-enabling a verified-only gate so the system simply cannot embed anything a human hasn't confirmed against the live page. We even held two documents back from going live because their sites blocked us and we hadn't finished checking them by hand. Leaving them out was the right call. The corpus grew from four shaky files to nine verified ones.

Going live was a saga in itself. The app compiled cleanly the whole time, but the deploy failed four separate times for reasons that had nothing to do with our code: a build-tool artifact our hosting platform couldn't finalize, a leftover build-command override, a configuration-format mismatch, and a hidden authentication wall that returned an error on every page. We traced each one, and the real fix was downgrading from a bleeding-edge version of our framework to a battle-tested one. Separately, our very first attempt to embed the corpus failed with an out-of-quota error: the API key was valid, but the account had no balance. We learned that a funded balance is its own prerequisite, separate from having a key.

The deepest challenge, though, was conceptual rather than technical: how do you put AI in front of vulnerable people responsibly? A confident wrong answer about a deadline or an address can cost someone a job, a bed, or a parole violation. Our answer shaped the entire architecture. Ground every answer in verified sources. Show those sources so the person can check our work. Refuse anything legal, medical, or parole-related and hand it to a named human. Keep the keys server-side and bound the cost. And make the AI draft, never decide; the caseworker commits.

Accomplishments that we're proud of

We're proudest that Alyosha is not a mockup. It's a real, deployed, two-sided product where both halves are genuinely connected through one shared database. A caseworker approves an intake plan and the returning citizen sees it appear as their map; the citizen checks off a step and the caseworker's dashboard updates to match. Building that round trip end to end, and getting it live where anyone can open it in a browser, proved the core idea works in practice and not just on a slide.

We're equally proud of the knowledge base behind the AI, because it's the part nobody sees and the part that matters most. Rather than scrape a shallow national dataset, we built the corpus by hand, one verified source at a time from official city and state pages and established nonprofits, recording the source and date on each. When we caught one of our own early documents being reconstructed from secondhand summaries instead of a clean source, we didn't paper over it. We re-verified it, then built a gate that physically refuses to embed anything a human hasn't confirmed against the live page, and we held back the sources we couldn't yet check. Choosing a small, trustworthy library over a large, shaky one is the discipline we're most proud of, because for this audience a confident wrong answer is worse than no answer at all.

What we learned

We learned that the most responsible thing an AI product can do is be clear about where it deliberately doesn't use AI, and where it refuses to act alone. We could have claimed intelligence everywhere; choosing not to, on the life-sequencing and on the high-stakes legal, medical, and parole questions, made the product more trustworthy rather than less. We also learned that an AI assistant is only as honest as the library behind it, so the unglamorous work of verifying sources and leaving out what we couldn't confirm was the work that counted. And we learned to be honest about where we stand: Alyosha is a working demo prototype, set in one city on purpose, built with fictional people and illustrative listings, and the real next step is people, not more code.

What's next for Alyosha

The immediate priority is production-grade privacy, because this population's data is uniquely dangerous to mishandle: a leaked record, parole status, or shelter address can cost someone a job, a lease, or their freedom. Before Alyosha touches a single real person's information, we will add real authentication, row-level security so each organization can see only its own clients and case notes, encryption at rest, and audit logging. The privacy-by-design principles are already in the product; hardening them into enforced infrastructure is the gate we have to clear first.

From there, the path widens: piloting with real reentry nonprofits and real returning citizens, expanding to more cities and partner organizations, and building out multi-language support and read-aloud for low-literacy and non-English speakers. Further out, the same engine could serve anyone stranded between fragmented services, including refugees, veterans, and young people leaving foster care. Because each interaction costs a fraction of a cent, the ceiling on Alyosha is reach, not compute.

Built With

  • chatgpt
  • claude
  • supabase
Share this project:

Updates