Ikigai

• 

  Logout/login

• 

  /ikigai

• 

  /check-ikigai

• 

  Replay(the website)

Inspiration

College has dealt us with several problems. We all knew that we were going to be back on assignments and vivas, but what we didn't expect was our homework to be buried under 300 messages of self-proclaimed "greatest" reviews of the Spider-Man movie (this was extremely recent).

Although it was an amazing movie, my professors didn't exactly sign our empty sheets with it.

After a great deal of begging and getting a lot of confused faces with the five stars (which were later explained weren't for the assignment but for the movie), we got ourselves a delay and a budget.

We moved our entire college group into Slack, where Ikigai morphed into a decision helper, minorly pivoting from its earlier role — much to the professors' happiness and our relief.

---

What it does

Ikigai is decision memory for Slack.

When someone proposes something that may have already been discussed, Ikigai searches the Slack history available to it and looks for the underlying decision — even when the old and new conversations use completely different words.

For example:

“Let’s move all database backups to one shared bucket.”

An older discussion might instead say:

“A single storage failure made every recovery snapshot unavailable at once.”

Traditional keyword search struggles here because the vocabulary barely overlaps.

Ikigai looks past the wording and tries to determine whether both conversations concern the same underlying decision.

It generates decision-specific search probes, retrieves relevant Slack discussions, transiently ranks them semantically, and then determines whether they actually represent useful precedent.

Instead of returning a pile of search results, Ikigai reconstructs the useful context:

1. What was previously decided

2. Why the team made that decision

3. What happened afterward

4. Whether it is current, disputed, superseded, or reversed

5. A link back to the original Slack thread

Ikigai works naturally inside Slack

@Ikigai <proposal>

Performs a public decision lookup in the current channel.

/ikigai <proposal>

Performs the same lookup privately, with an ephemeral result visible only to the requester.

DM Ikigai

Allows private searches across channels the bot can access.

/check-ikigai @username

Examines someone's calls in the current discussion and identifies who supported or opposed them.

Catch up after being away

Ikigai can even help when you return after being away.

/ikigai logout records when you leave, while /ikigai login generates a private catch-up of relevant decisions that happened while you were gone, with links directly to their Slack threads.

Most importantly, Ikigai knows when not to talk.

Greetings, thanks, emoji-only messages, and conversations that do not contain meaningful decisions are filtered out.

Ikigai isn't meant to become another bot generating noise in an already noisy workspace.

---

How we built it

We built Ikigai as an agentic decision-retrieval pipeline integrated directly with Slack, using Google ADK, Gemini, FastAPI, Cloud Run, and Firestore.

When a request comes from a Slack @mention, slash command, DM, or our Replay UI, it first passes through a security layer that validates Slack HMAC signatures, API tokens, and removes duplicate Slack event retries.

FastAPI running on Google Cloud Run acts as the central backend and is the only component that communicates with Gemini.

From there, the request moves through an ADK sequential pipeline:

Prefilter → Gate → Search Probes → Retrieve → Rank → Decision Lookup

1. Prefilter and Gate

The prefilter removes greetings, acknowledgements, and other low-value messages without making a model call.

For the passive watcher, Gemini 3.5 Flash-Lite acts as a lightweight gate to determine whether a message represents a decision worth investigating.

Direct commands skip this gate.

2. Search Probes and Retrieval

If a decision needs investigation, Ikigai generates heuristic search probes without using an LLM.

These probes retrieve potentially relevant discussions from Slack, along with existing structured decision information from our Firestore decision graph.

3. Transient Semantic Ranking

The retrieved Slack discussions are converted into untrusted notes rather than being passed to Gemini as raw Slack quotes.

gemini-embedding-001 creates temporary embeddings to semantically rank the retrieved information.

These vectors exist only in memory and are discarded immediately after ranking.

4. Decision Lookup

The highest-ranked context is passed to Gemini 3.5 Flash, which performs the final decision lookup and briefing.

It determines:

• What was previously decided

• Why it was decided

• How the historical decision relates to the current proposal

5. Decision Card

FastAPI converts the result into a structured decision card, which can be returned as Slack Block Kit or JSON for the Replay UI.

Gemini never communicates directly with the browser or Firestore.

---

Privacy-first architecture

We deliberately designed Ikigai without a permanent vector database of Slack conversations.

Firestore stores only derived decision metadata such as:

• Status

• Confidence

• Labels

• Relationships between decisions

• Permalinks to the original discussions

Ikigai does not persist:

• Raw Slack messages

• Slack user IDs

• Content embeddings

• A persistent vector index

---

Architecture

The complete pipeline works roughly like this:

Slack / Replay UI

    ↓

Security Layer

    ↓

FastAPI on Cloud Run

    ↓

Google ADK Pipeline

    ↓

Prefilter → Gate

    ↓

Heuristic Search Probes

    ↓

Slack + Firestore Retrieval

    ↓

Transient Semantic Ranking

    ↓

Gemini Decision Lookup

    ↓

Decision Card

    ↓

Slack / Replay UI

---

Challenges we ran into

Finding decisions without storing Slack

Our biggest challenge was cross-vocabulary recall. Slack search struggles when people describe the same problem differently, and our earlier keyword-based pipeline hit a recall ceiling of 72.5%.

At the same time, we didn't want to permanently store message text, user IDs, embeddings, or a workspace-wide vector index.

We solved this with a content-free Firestore decision graph + live Slack retrieval + transient embed → rank → destroy pipeline. We also had to distinguish genuine decision reversals from concurrent approaches — incorrectly calling something "reversed" could be worse than missing it entirely.

Building an agent that knows when to stay silent

Ikigai couldn't behave like a normal chatbot. ADK SlackRunner responds to every DM and mention, while Ikigai should only appear when useful.

So Slack Bolt owns the Slack events, while ADK owns the reasoning pipeline. A zero-model prefilter removes greetings, thanks, and other chatter before Gemini is called, reducing both noise and cost.

The UX also went through several iterations before we settled on:

• @Ikigai → public decision lookup

• /ikigai → private, ephemeral lookup

Even the decision cards evolved from too cold → too narrative → finally concise and useful.

Slack and Cloud Run

Slack introduced several deployment constraints. Slash commands must be acknowledged within 3 seconds, so Cloud Run's scale-to-zero cold start wasn't reliable enough for our live demo and we kept one minimum instance running.

We also learned that Socket Mode works well locally but conflicts with the HTTP architecture needed for Cloud Run, requiring us to separate the two approaches.

Gemini, Vertex AI, and deployment

Our first live @Ikigai request returned a 403 because the Cloud Run service account lacked the required Vertex AI permission. After fixing IAM, we hit a 400 because thinking_level wasn't supported by our fallback model.

We updated the client to retry without thinking configuration and fall back across models.

Deploying from Windows added another layer of problems involving PowerShell execution policies, Python versions, gcloud authentication, environment-variable expansion, Firestore configuration, and API authorization.

Keeping costs under control

Cost became an architectural constraint rather than an afterthought.

We replaced an unnecessary Flash-Lite probe-generation call with heuristics, reduced redundant model calls, and controlled model thinking levels.

We also added budget safeguards:

• $10 daily pause

• $40 hard stop

These challenges pushed us to make Ikigai not only more accurate, but also quieter, more private, cheaper, and more reliable in production.

---

Accomplishments that we're proud of

We’re particularly proud that Ikigai isn’t just a chatbot connected to Slack.

It behaves more like a small piece of organizational infrastructure, helping teams recover the reasoning behind decisions when that context matters.

Ikigai can:

• Recognize precedent where traditional keyword search fails

• Distinguish current decisions from reversed or outdated ones

• Reconstruct the reasoning surrounding a previous decision

• Link users directly back to the original Slack discussion

Public and private by design

We’re also proud of making public and private interactions fundamentally different.

A user can privately investigate a decision using /ikigai before deciding whether that context should become part of the wider conversation.

When someone explicitly mentions @Ikigai, the result can instead become part of the shared discussion.

This gives users control over when organizational memory stays private and when it becomes collaborative context.

Privacy-first architecture

Another accomplishment we’re proud of is Ikigai’s privacy architecture.

Ikigai does not need to permanently store:

• Slack message text

• Slack user IDs

• Persistent message embeddings

• A workspace-wide vector index

Semantic representations can be generated temporarily for ranking and then discarded once the search is complete.

Replay UI

We also built the system so the same agent pipeline can operate against our fixture workspace through the Replay UI.

This allows someone to experience Ikigai’s core decision-memory functionality without requiring Slack credentials or access to our development workspace.

---

What we learned

The biggest thing we learned is that organizational memory isn't really a search problem.

Search answers:

“Where was this mentioned?”

Decision memory needs to answer:

“Why did we decide this, what happened because of it, and does that reasoning still apply?”

We also learned that good agents don't necessarily need to do more. Sometimes, they need to know when to do nothing.

For an agent living inside a communication platform, silence is a feature. If Ikigai responded every time it detected something vaguely related to an old conversation, people would quickly stop paying attention.

Finally, we learned that memory and privacy don't have to be opposites.

An agent can preserve the structure, status, and relationships between decisions without permanently preserving every conversation that produced them.

---

What's next for Ikigai

The future of Ikigai is the same product, grown: decision memory that compounds with every call, while still never storing Slack conversations.

Better live recall

Ikigai already finds previous decisions across completely different vocabulary. Next, Slack Real-Time Search with the user's action_token can extend that recall into private channels while inheriting the user's existing permissions.

Slack text remains only in request memory and is never added to a permanent archive.

Memory that compounds

Every new decision can strengthen Ikigai's decision graph.

Instead of storing the original message, Ikigai keeps only derived information such as:

• Labels

• Decision status

• Permalink

• Relationships between decisions

As the graph grows, Ikigai can check its existing decision memory first and then re-fetch the original Slack thread live when context is needed.

The result is memory that becomes more useful through normal usage rather than through crawling and permanently indexing the workspace.

Smarter decision cards

The decision card can also become more interactive.

If two possible precedents are extremely close, Ikigai can ask one clarifying question instead of guessing.

A “Not the same” action can strengthen the graph by recording that two decisions are unrelated, while Share can let the user review and edit a short summary before posting anything publicly.

Login catch-up can then use the decision graph that has been building throughout the week, rather than summarizing a giant dump of Slack history.

Decision memory for other agents

Ikigai's memory does not have to be useful only to Ikigai.

Other agents can query the same decision layer through MCP, using capabilities such as query_decisions and check_supersession, instead of independently scraping Slack and rebuilding the same organizational context.

Org-scale, still quiet

As Ikigai grows, one principle stays unchanged:

It should not become another chatbot that constantly interrupts the team.

A limited, text-free warm-up can help initialize a new workspace, but Ikigai does not need to crawl thousands of historical searches to become useful.

The goal is simple: as teams make more decisions, Ikigai's memory gets better.

Teams stop relitigating old decisions in new words, stop accidentally following reversed guidance, and stop confusing two valid parallel approaches for a single winner.

The product grows. The memory compounds. The agent stays quiet.

Built With

• artifact-registry
• cloud-build
• cloud-firestore
• docker
• fastapi
• gemin-3.5-flash-lite
• gemini-3.5-flash
• gemini-embedding-001
• google-adk
• google-cloud-run
• python
• react
• secret-manager
• slack-api
• slack-block-kit
• slack-bolt
• tailwind-css
• typescript
• vertex-ai
• vite