Seepdeek

Inspiration

Seepdeek was inspired by the way work gets scattered across Slack, Linear, and other tools. Important requests often appear as casual messages, issue comments, status updates, or follow-ups, and it becomes easy to lose track of what actually needs action. The goal was to build a focused assistant that turns those signals into one prioritized task queue.

## What We Built

We built a FastAPI and Next.js application that ingests work signals from Slack and Linear, stores them as raw events, and runs an LLM-powered resolver to decide whether each event should create, update, close, ignore, or review a task.

The backend keeps raw_events as the source of truth and creates canonical tasks from them. Slack and Linear both flow through the same resolver path, and the resolver can use provider-specific tools to gather context before making decisions. Linear support includes OAuth, webhook ingestion, issue context lookup, and tools for updating or closing Linear issues when the local task lifecycle changes.

## How We Built It

The project uses:

• FastAPI for the backend API and webhook/OAuth routes.
• SQLAlchemy and Postgres for persistent events, tasks, connected accounts, and resolver runs.
• Next.js for the frontend task dashboard.
• Slack Socket Mode and OAuth for Slack ingestion.
• Linear OAuth, webhooks, and GraphQL for Linear integration.
• OpenAI-powered resolver logic with bounded tools for context retrieval and provider-aware actions.

The core architecture is evidence-first: every inbound provider event is stored before reasoning happens. The resolver then inspects nearby tasks, related events, and provider context before deciding what lifecycle action to apply.

## What We Learned

We learned that task resolution is less about detecting keywords and more about preserving context. A message like “looks good” might be meaningless by itself, but if it follows a delivered proposal, it can mean the task is complete. That pushed us toward a resolver that always retrieves context before deciding.

We also learned that provider integrations need clear boundaries. Read tools are safe for context, but write tools need stricter guardrails, especially for Linear issue updates and closing tickets.

## Challenges

The hardest part was designing a resolver that is flexible enough to understand messy human communication while still being safe and predictable. We had to balance LLM reasoning with backend validation, structured outputs, retry behavior, and bounded tool access.

Another challenge was keeping Slack and Linear events provider-agnostic while still preserving enough metadata to update the right local task or Linear issue later. OAuth scopes, webhook signatures, and deployment requirements also added practical integration complexity.

## What’s Next

Next steps include improving task merge logic, adding Gmail and Google Calendar ingestion, building approval flows for outbound actions, and replacing the hackathon-style schema bootstrap with a proper migration workflow.

Built With

• nextjs
• nginx