Why Ian On
The problem Ian On was built to solve, the idea behind it, and how a company actually uses and runs it.
Most "AI at work" today is a chat box. You ask, you get an answer, and you still do the work yourself. Ian On started from a different idea: a place where your company doesn't just get answers, but gets work finished.
The problem: the tools multiplied, the work didn't
Three things kept getting in the way.
- A chatbot answers once and stops. It only works while you're asking, and you re-explain the same background every time. The knowledge never accumulates anywhere your team can reuse it.
- Ordinary search returns fragments. It pulls a few similar-looking sentences, but the context that actually matters — how things relate, which policy applies, who decided what and why — stays outside the results.
- Good answers meant giving your data away. To get quality, teams sent internal documents to outside models, and control and auditability came second.
The idea: an operating brain your company owns
Ian On is meant to be the place where your company's judgment compounds. Decisions approved in your work, documents you upload, and knowledge that passes review build up in a shared memory that your company owns and runs, while what Ian remembers from your personal conversations stays separately in your personal memory. It isn't one big model doing magic. The AI models you connect, a curated memory, a relationship graph, and your Agents work together, so the whole system fits your company better the more you use it.
That's the vision in one line: an operating brain, owned by your company, where people's judgment builds up over time instead of evaporating in a chat history.
How it's different
| A chatbot | RPA / scripts | Ian On | |
|---|---|---|---|
| Unit of work | one-off Q&A | a fixed script | a goal → a finished result |
| Memory | the session only | basically none | curated index + graph + a decision ledger |
| Where data lives | sent to outside models | internal, but rigid | stored on your company's infrastructure; with external AI, what it processes is sent to that provider |
| Over time | same quality, forever | scripts go stale | company context accumulates; answers improve |
The short version: a chatbot answers, and Ian On finishes the work — and leaves a record you can trust.
How a company uses it
Day to day, the flow is simple.
- On Home, open Talk to Ian and ask for what you need.
- Ian either answers on the spot or starts Work on it. At steps that need a decision, it asks you to approve or choose.
- A team of agents runs it. You can watch and steer.
- The finished result is kept in History as a record — including who approved or rejected it.
- What builds up in memory becomes the ground the next task stands on.
What teams hand off looks different by department but rhymes: a weekly market-intelligence brief for strategy, account insights for sales, a daily data-quality check for data operations, a policy-and-compliance check for security and legal. Ian On isn't tied to one of these — work is defined to fit your company's own domain, and it fits better the more you run it.
Who owns and runs it
Ian On is installed and run on your company's infrastructure. If you use external AI, the data needed for answers or document analysis may be sent to that provider. Access is governed by four roles plus per-item permissions, and people with the Owner and Admin roles check the record of key admin actions, such as role changes and password resets, in Admin → Audit. You can connect both local models and external AI. Every user manages their personal connections in Settings → My AI Connections, and owners and admins manage the Organization AI Defaults in Admin → AI providers.
Ready to try it? Head to Getting started.