Reboard: Return to Work, Reconstructed

Inspiration

When I was born, my mom went on parental leave. When it was time to come back to work, she couldn't. Not because she didn't want to, and not because she wasn't capable, but because she couldn't catch up. Nothing in her workplace was built to hand the story of what happened while she was away back to her, and that gap alone was enough to keep her from returning at all.

That's stayed with us. Return to work tools treat "catching up" like a minor inbox problem, something you push through with a long Monday. But for someone coming back from parental leave, medical leave, or any extended absence, it isn't an inbox problem. It's a context problem, and for some people, like my mom, it's a big enough barrier to keep them from going back at all. As product managers, we kept asking why nothing existed to actually solve that. We built Reboard because we don't think that gap should exist for anyone else.

What it does

Reboard combines email, calendar events, meeting changes, and employee role context into a single prioritized return briefing. Instead of summarizing messages one at a time, it reconstructs the underlying storylines connecting them: an invite, its reschedule, the decision that came out of it, an ownership handoff, and a moved deadline all become one connected change instead of five separate emails. It then ranks those storylines against the returning employee's actual role, deadlines, and dependencies, so the briefing tells you what changed, why it matters, and what to do first. From there you can expand the evidence behind any storyline, ask a grounded question about what happened, and generate an editable reply that always requires manual review before sending.

How we built it

Reboard is a Next.js App Router application in React and TypeScript with Tailwind CSS. Email and calendar access are built behind provider independent interfaces, EmailProvider and CalendarProvider, so the same pipeline can run against demo fixture data or, eventually, real Google accounts through a shared normalized contract.

GPT 5.6 is used in two separate passes. The first reconstructs cross source evidence into connected work storylines. The second, run separately, prioritizes those storylines by role impact, deadlines, dependencies, and responsibilities. Outputs are constrained with Zod schemas converted to strict JSON Schema, and a deterministic fallback mirrors that same output contract so the public demo stays reliable even without live credentials. Codex accelerated the build by scaffolding the provider contracts and API routes, generating connected fixture data across nine kinds of workplace change, implementing the strict schemas and fallback path, and helping assemble the briefing UI, evidence viewer, grounded Q&A, and editable reply flow.

Challenges we ran into

Live Google OAuth and ingestion are still stubs, so keeping the demo genuinely reliable without real credentials meant building a deterministic fallback that mirrors the AI pipeline's exact output shape rather than faking a simpler version of it. Grouping cross source evidence correctly was harder than it looks: deciding that an invite, a cancellation, a reschedule, and a decision email all belong to one storyline requires reasoning across sources together, not scoring each message independently. We also had to separate reconstruction from prioritization as two distinct passes, since a single combined pass kept letting recency and message volume dominate the ranking instead of actual role relevance. And on a personal level, it was harder than expected to turn a private family story into a product brief without losing what made it true in the first place.

Accomplishments that we're proud of

We built an end to end working experience, not just a technical proof of concept: a real reconstruction pipeline, a real evidence viewer, and a fixture demo that runs reliably without any account setup. The three way contrast we landed on, traditional summary versus reconstructed storyline versus role aware priority, ended up being the clearest way we found to explain why this isn't just another summarization wrapper. Most of all, we're proud that we built something grounded in a real reason someone couldn't return to work, rather than starting from a technology and looking for a problem to attach it to.

What we learned

The biggest lesson was architectural: prioritization has to be a separate reasoning stage from reconstruction, or importance quietly collapses into recency. We also learned that reconstruction is genuinely a multi source problem, a single email rarely tells you enough to judge how much it matters, but the full chain around it usually does. On the product side, we learned that people don't actually want more summarized content after time away, they want fewer, better ranked things to act on first, and that for some people that gap isn't an inconvenience, it's the difference between returning to work or not.

What's next for Reboard: Return to Work, Reconstructed

Our immediate roadmap is completing real read only Gmail and Calendar ingestion behind the provider interfaces we already built, adding citation validation to grounded Q&A and reply generation, and moving to encrypted short lived sessions instead of any persisted raw content. Beyond that, we want to add Outlook support and organization specific terminology, and evaluate Reboard's reconstructed briefings directly against human written ones. Longer term, we want to reach the people who need this most: those returning from parental leave, medical leave, or any extended absence, for whom catching up isn't just tedious, it's the barrier standing between them and going back to work at all.

Built With

• css
• next.js
• react
• typescript