KrooloAI and productivity software
Kroolo is an AI work operating system: projects, tasks, goals and documents in one workspace, with generation and agents built into the work itself. We sat with Kroolo's team for the length of the project and built the AI layer inside it: prompt to project generation, the agent catalogue and the automations that write back into the workspace, across web, Android and iOS. The brief sat between work management platform development and AI productivity platform work, and the tenant boundary decided both.
Build fingerprint
Where it runs, how we engaged, and what it was built on.
Technologies
What makes this problem genuinely hard - before any client name enters the page.
In a relational store the tenant filter is one predicate the ORM will not let you forget. Move that data into a vector index and the boundary becomes a metadata filter, and a filter applied after the nearest neighbour search is weaker than one applied inside it. Embeddings are derived copies, so deletion and permission changes have to reach the index, not just the row.
Per seat pricing assumes cost per account stays flat. Put a model call inside a feature people use all day and cost tracks usage instead, with a thin slice of accounts generating most of it. You need metering at the unit the price is set on, a budget enforceable mid request, and a degraded answer rather than a failure when it is hit.
The same input will not return the same answer twice, so assertions stop being the safety net. A fixed evaluation set scored before release replaces them, plus production signals: how often a draft gets edited, regenerated or abandoned. None of it is attributable unless prompt and model version are stored with the output. Latency counts here too, because a call inside a click has the interaction's budget, not the API's.
An agent that creates tasks and edits documents needs its own identity, scoped to what the person invoking it could already do, never a service account. Every action wants an audit row naming the agent and the human behind it. And whatever an agent does, a human has to be able to reverse.
Kroolo sells an AI work operating system to teams anywhere: projects, tasks, goals, documents and collaboration in one workspace, on the web and both mobile stores. What separates it from a task tracker is where the AI sits. Each workspace is its own tenant, and the retrieval behind an answer has to read that workspace and nothing past it. Multi-tenant SaaS problem and AI infrastructure problem at once, and the two refuse to separate.
Turns a written brief into structured work: tasks, sub-tasks, owners and dates written as real records in the workspace, not chat text a user copies out.
The surface behind Chat with Anything, answering from a user's own projects, tasks and documents, scoped to the asking workspace.
Agents that act on work items rather than describe them: drafting, updating, summarising, writing results back into the workspace.
Analytics computed from the records the agents write, plus workflow that adapts to observed team patterns. One graph, both directions.
Tradeoffs
Every choice closed off something else. Those costs are stated, not hidden.
Instead of: Everything in Node, calling models over HTTP. The model side moves at its own pace in a Python ecosystem, so an inference change need not force an API release.
What we acceptedTwo runtimes, two dependency chains, a boundary crossed on a hot path.
Instead of: A relational schema per entity type. Projects, tasks, goals and documents are heterogeneous, and generated content adds shapes no schema anticipated.
What we acceptedRelational guarantees now enforced in application code, and cross-entity reporting that costs more than a join.
Instead of: A PaaS with per service scaling. Model serving and CRUD have different resource profiles, so splitting them at pod level stops a burst of generation starving the app.
What we acceptedA cluster to run, upgrade and secure, a standing cost paid every quarter.
Reusable
Six layers where a multi-tenant AI feature can leak, and what escapes at each one if the check is missing.
| Layer | What enforces isolation | What leaks if you skip it |
|---|---|---|
| Request | Workspace resolved server side | A client-supplied workspace id |
| Retrieval | Tenant id as a pre-filter, not a post-filter | Neighbours from another tenant, silently ranked |
| Prompt assembly | Chunk permissions re-checked at query time | A document revoked yesterday, quoted today |
| Model call | No cache keyed on prompt text alone | One tenant's answer served to another |
| Agent action | Agent inherits the invoking user's rights | An agent writing where the human cannot |
| Deletion | Embeddings on the record's delete path | Data outliving its own deletion request |
Retrieval is the row most often missed, because a post-filter looks correct in every test that only queries one tenant.
Delivery
Capabilities delivered and the scope of the build - not results attributed to it.
Capabilities
Scope
Scope of the build, not results attributed to it.
Bring us the part you think is hardest.
A retrieval bug in a multi-tenant product is a disclosure, not a display fault, so isolation is tested at every layer in the table above.
The product and both store listings sit with Kroolo, and running on Kubernetes keeps the deployment portable rather than tied to one vendor's primitives.
The split between API services and model serving is also the handover line.
Reflection
Evaluation is what we would do differently. We treated it as something to add once the AI features settled, which is backwards: a frozen evaluation set is cheapest to build while a feature is new and people are still arguing about what a good answer looks like. Retrofit it and you are reconstructing intent from prompts already in production. Cost attribution is the other gap: spend per feature per workspace is what pricing needs, and one user action can fan out into several calls.
Three. Web at kroolo.com, Android as com.kroolo.app, iOS as App Store id6740263578. All three are public listings, so the claim is checkable without asking us.
Filter during the search, not after it. A tenant predicate applied to the results of a nearest neighbour query is weaker than one applied inside it. Then re-check document permissions at query time rather than trusting index time.
You score instead of asserting. A fixed input set with graded expectations, run every release, plus what users do next: edits, regenerations, abandonment. Store prompt and model version or a regression cannot be traced.
Context
Tell us what your operation runs on today.
Real feedback from the people we've proudly partnered with.
Sales Director |Cintas
United States
Zyneto Global Technologies provided excellent project management and technical expertise throughout the engagement. The team was responsive, collaborative, and adaptive, ensuring the project met our expectations and set a strong foundation for future growth.
Founder & CEO |Moneteo
We engaged Zyneto to design and develop a custom web platform for Moneteo, aimed at improving project management, data tracking, and collaboration across internal teams and external partners. Their work included full-stack web development, custom modules for workflow automation, API integration, and comprehensive testing.
CEO |E-Commerce Platform
Overall, their responsiveness and timely deliveries contributed positively to the project's success. The client achieved better data management and quality. The service provider delivered the project on time and ensured prompt responsiveness throughout the engagement. Their innovative approach was outstanding.
