Agentic Process Discovery
The problem
Most recurring workflows inside an organization are never written down. Expense approvals, project handoffs, scheduling chains exist as informal patterns spread across email threads and chat histories. Traditional process mining tools need structured event logs. They can’t read an inbox.
So when someone asks “how does our expense approval process actually work?”, the answer is usually “check with whoever’s been doing it the longest.”
What it does
You type a process topic in plain language (e.g. “expense approvals”, “meeting scheduling”, “project handoffs”) and the system retrieves relevant communications and produces a structured breakdown: ordered steps, what triggers each one, who owns it, and where things tend to get stuck.
The design is shaped around the assumption that the communications being analyzed are sensitive. Everything is run locally. No email content, message history, or generated output is sent to an external API.
Indexing phase
Query and inference phase
Architecture
Key design decisions
Two-stage retrieval instead of a single query. One query against a process topic only surfaces messages that literally match the topic phrase. Query expansion instead rewrites the topic into stage-targeted searches, each phrased as a description of the kind of message that would represent that stage, so retrieval covers the full lifecycle even when those stages are never worded like the topic itself.
Reply filtering before embedding. Reply chains repeat the same content under multiple senders and pull cosine similarity rankings toward noise. Only original messages are indexed; replies are dropped at ingestion.
Source-aware chunking. The index unit differs by source because email and chat carry context differently.
Email per message
Each email is indexed on its own. A message is already a self-contained unit, so one vector maps to one message.
WhatsApp 30-min window
Chats are windowed on a configurable gap threshold (default 30 minutes), because a single chat message out of context often means nothing.
Local by design. Everything runs on the machine: Ollama and Llama 3.2 for generation, ChromaDB for storage, spaCy NER plus regex for PII masking before anything is shown. The tradeoff is deliberate, since local setup takes longer than an API call, but sensitive workflow data never leaves the device.
Local by design, nothing leaves the device
Private- ✓Read-only OAuth. Gmail access cannot modify, send, or delete.
- ✓On-device inference. Llama 3.2 runs locally via Ollama, no external API call.
- ✓Local vector store. ChromaDB collections stay on the machine.
- ✓PII anonymization. spaCy NER plus regex masks names and phone numbers before output.
What this means for clients
The same architecture works for any organization with undocumented processes buried in communication data: Slack exports, customer email histories, support threads, vendor correspondence. The system maps process structure without requiring any prior instrumentation or schema definition.
If a workflow currently lives only in people’s heads and inboxes, this reconstructs it from the evidence that’s already there.
Technologies:
Python ChromaDB Ollama Llama 3.2 BGE-base-en-v1.5 Gradio spaCy Gmail API Docker
Concepts / Algorithms:
Agentic Process Discovery RAG Query Expansion Vector Embeddings Semantic Search Named Entity Recognition (NER) LLM Inference