Why We’re Designing Smart Employee as a Modular Product
Why we chose one shared AI employee architecture with optional modules—and where we draw the line between working components and a finished product.

Smart Employee is not a finished collection of modules today. It is a product architecture we are designing: one AI employee with a shared identity, memory, permissions and workspace, able to gain new capabilities over time.
The problem started with product names
When every capability becomes a separate product, the customer also inherits separate accounts, settings and histories. That fragmentation makes a digital team harder to understand and harder to manage.
So we asked a simpler question: should secretary, support, sales and social-media work be unrelated applications, or different roles of the same AI employee?
One shared core, optional modules
Our direction is one shared core for the business profile, preferred language, memory, permissions and daily workspace. Optional modules then add focused capabilities such as secretary, customer support, sales, social media and operations.
A module is not just a menu item. It should perform a defined job, use explicit tools and permissions, follow a clear workflow and have a measurable result.
What exists today—and what does not
We already have working building blocks: answering pipelines, a knowledge base, contacts and messages, tickets and human handoff, media storage and internal reporting. These components have real operating history.
But they currently serve specific business environments. They are not yet a tenant-isolated, self-service Smart Employee product. Customer onboarding, strict data separation, configurable workflows and a complete customer panel still need product work.
That distinction matters: strong raw material does not mean every module is already available.
Why language belongs in the core
Language affects more than translated buttons. The interface may use one language while a customer conversation uses another. Tone, terminology and right-to-left presentation also need to remain consistent.
Keeping language in the shared core helps every future module follow the same rules instead of creating a different voice in each tool.
The commercial model follows the architecture
A shared core with optional modules can eventually support a clear commercial model: customers activate the capabilities they need and usage can be measured per module.
This is a product direction, not a promise that every package is available today.
A useful rule for agentic products
People do not pay for a collection of menus. They pay for completed work.
That is why we want to judge every Smart Employee module by the outcome it delivers. The goal is one coherent AI employee that can grow with the business, rather than several disconnected applications.
We have working components and a tested architectural direction. The multi-customer product around them is still being built.
Ask a question
Got a question about this post? Drop your email and we’ll reply.
Get notified of new posts
1–2 emails per month on the Türkiye marketplace and AI. No spam.
Related posts

Live on a Server Is Not the Same as Recoverable: A Lesson from Our Agentic Team
An independent review found that several live changes were not yet recorded in version history—a practical lesson about what Done really means.

How We Moved Blog Image Uploads from Manual Server Work to the Admin UI and CDN
TekeraLab already had a CDN. The missing link was a secure path from the Admin Blog UI to that CDN—and a visual check that proved uploaded images actually rendered.

What Is the TekeraLab Logbook—and How Did It Become Our Content Radar?
TekeraLab built a shared memory for people and AI agents. Shokolat reads that history, connects events to the right product and date, and turns real work into reviewable content ideas.