Product engineers define agent workflows with typed inputs and outputs, then plug them into web, mobile or CLI apps, on whichever model provider fits.
Role
Architect, LeanScale
Status
Client work
Period
to
Stack
Rust,SurrealDB,React,Tauri
Source
Not public
From public tool to internal engine
Athena started as a public AI agent tool. Before building it I researched the market fit, and what came back was clear enough: the strongest use for it was inside LeanScale, where the team was building agents all the time. So it became an internal logic engine for building and running agent workflows, and I architected it.
How Athena fits together
Product engineers define workflows; the engine runs them against any model provider and hands results to the apps that call it.
Workflows with real contracts
The people using Athena are product engineers, so it treats a workflow like any other piece of software: it has a contract. Each one declares its input and output schemas, and that is what lets it plug into a web app, a mobile app or a CLI without glue code that guesses at the shape of an answer.
Any model, your own key
No single model is best at everything, and teams already have accounts with the providers they like. Athena works with most of the major providers and models, and teams can bring their own keys. It is multi-tenant, and usage is tracked in credits, so every team can see what its agents cost.
Running the app stores
One workstream ties Athena to the Apple App Store and Google Play. Agents manage app listings, reply to store reviews, organise screenshots and handle translations: the steady, repetitive work that eats a product team's week.
Past the chatbot
Athena is built for agentic work, not chat. Agents can talk to each other, memory nodes give them context that carries from one run to the next, and generative UI lets an agent render an interface for its answer instead of a wall of text.
This was internal work at LeanScale, so the code is not public.
IST --:--Based in India. Works with teams in any time zone.