[Submission] Aktilot – AI Document Chat using RAG with Durable Temporal Workflows

[vikas0686]

Project link

https://github.com/vikas0686/Aktilot

Language

Python

Short description (max 256 chars)

Aktilot is an open-source, self-hosted AI document chat platform powered by Temporal. Document ingestion and chat run as durable workflows with retries, checkpointing, observability, and hybrid BM25 + vector retrieval.

Long Description

Aktilot is an open-source, self-hosted AI document chat platform that demonstrates how Temporal can orchestrate reliable AI workflows.

The project uses Temporal to coordinate long-running document ingestion and chat pipelines instead of traditional synchronous request flows.

Current workflows include:

• DocumentWorkflow – chunks documents, generates embeddings, and indexes them into ChromaDB with durable retries and checkpointing.
• ChatWorkflow – performs hybrid BM25 + vector retrieval, reranking, LLM response generation, and conversation persistence as a durable workflow.
• BenchmarkWorkflow (planned) – evaluates retrieval quality and latency across different retrieval strategies.

The project demonstrates several Temporal patterns including:

• Durable execution
• Activity retries
• Long-running workflows
• AI pipeline orchestration
• Failure recovery without restarting completed steps
• Workflow observability

Aktilot is intended as both a production-ready self-hosted document AI platform and a reference implementation for engineers building AI systems with Temporal.

Feedback and contributions are welcome.

Author(s)

Vikas Pandey
Principal Software Engineer | Open Source Contributor

GitHub: https://github.com/vikas0686
Website: https://vikaspandey.dev/
LinkedIn: https://www.linkedin.com/in/vikaspandey0686/

[github-actions]

ZiggyBot — automated pre-evaluation

---

Criterion	Assessment
Useful to Temporal users	✅ Yes — Demonstrates orchestrating a RAG ingestion/chat pipeline as durable workflows with per-activity retry policies, a relevant reference for AI-on-Temporal use cases.
Benefits clearly explained	✅ Yes — README and submission describe the problem, workflow responsibilities, and checkpointing/retry behavior in concrete terms.
OSI Approved License	✅ Yes — MIT license is present and classified by GitHub.
README with working instructions	⚠️ Unclear — Instructions are detailed but the clone URL uses a placeholder (https://github.com/your-org/aktilot.git) that does not match the actual repository, and the setup could not be verified end-to-end.

Overall: Needs review ⚠️

Notes:

• The clone URL, issue links, discussion links, and security policy references all point to your-org/aktilot rather than the actual vikas0686/Aktilot repository, suggesting templated content that was not fully updated.
• README references docs/aktilot-01-03.png and eight screenshot files plus CONTRIBUTING.md and SECURITY.md; presence of these files was not verified from the provided data.
• BenchmarkWorkflow is described as planned/coming soon in both the submission and README; current functional scope is the two implemented workflows.
• Repository has 1 star and no fork history; maturity and external usage are minimal.
• Both source files were truncated, so retry-policy application and the error-handling paths described in docstrings could not be fully confirmed.
• Distinct retry policies are differentiated by failure class (OpenAI calls vs. infrastructure operations), which is consistent with documented Temporal retry guidance.

Suggested questions for submitter:

• Can the clone URL and the issue/discussion/security links in the README be corrected to point to the actual repository?
• Are the referenced architecture and screenshot images and the CONTRIBUTING.md/SECURITY.md files present in the repository?
• Is there a test suite backing the pytest and npm test instructions, and does CI run it?

Notable Temporal pattern:

Per-activity retry policies differentiated by failure type within a single workflow: OpenAI-bound activities use a bounded exponential backoff while infrastructure operations (Postgres, ChromaDB) use a higher-attempt policy, with non-retryable application errors used to bypass retries for cases like NOT_FOUND. This represents granular failure-recovery configuration where individual checkpointed steps retry in isolation without re-running completed work.
View in source ↗

---

Automated AI pre-screen by ZiggyBot. Final decisions are made by the community team.

Reviewer: Check the box below to generate a Contentful-ready long description for this submission.

• Generate long description if needed

[vikas0686]

updated the README file.