How does a czak work?

A dedicated AI system configured for a defined area of work. It combines models, memory, tools, data and operating rules. We agree the goal and the limits of its autonomy with you; the czak then organises and carries out work within that scope. You are not simply buying model access or instructions to paste into a chat.

The conversation establishes what needs to get done. The work also includes the steps that follow: using tools, retaining decisions, creating or developing a solution and checking the result. The outcome can be a working application, an organised case or an analysis with supporting records — not just an answer in a chat window.

No. It can extend the capabilities of an individual, specialist, manager, business owner or team. The starting point is the work you want to do better, not your technical knowledge. We fit the deployment to the actual problem and scale of operation.

That is not the product’s purpose. A czak extends people’s abilities and takes on an agreed scope of execution. Humans retain decision control: they set the goal, the rules and the actions that need approval. A “digital twin for work” is not a copy of a person or permission to make arbitrary commitments on their behalf.

Yes, when it runs in an active environment designed for background work. Closing the page does not have to end the task. With a local deployment, the computer and required services must remain available. A czak can also wait for an event or your decision rather than continuously performing more operations.

A czak uses the retained decisions and current state of a case, so your next instruction can build on earlier work. That does not mean remembering everything without limits: the scope of memory, available sources and data retention need to be defined for the deployment.

The czak should relate the change to existing decisions, identify its consequences and adjust the remaining work. If the new direction requires more budget, additional access or another human decision, it does not automatically authorise a wider scope. The new boundaries need to be agreed first.

We agree what counts as completion: for example, a working solution, a saved document, an agreed report or a check result. A message saying “done” does not replace the outcome. The scope of verification and outstanding work should be visible; a check performed by the producer is not an independent audit.

Channels connected to one czak can lead to the same identity and the same authorised cases. Changing where you talk does not have to mean a new bot or starting again. Connections are configured as part of a deployment; a self-service connection panel is a planned part of the sandbox.

No. Connecting an account requires proof of control and an agreed access scope appropriate to the service. An address or username alone grants no permissions. We separately define whether the channel is only for talking to you or also for working with messages and taking actions.

It should not. Talking to a czak is a different scope from granting it access to an inbox, message history or company channel. The deployment defines which conversations, folders and data are needed. Available access restrictions also depend on the service and connector; we check them before connecting the account.

These channels can be part of a deployment. We also use mautrix messaging bridges; the connection depends on the service, available permissions and intended use. This does not mean every channel has identical features or is already available for self-service connection in a public demo.

Yes. Existing deployments use RPA automation with Saldeo and InsERT/Subiekt. These are existing integrations, not just future ideas. Before enabling them in another environment, we check the system version, available operations and permissions. The public demo is intended to describe these capabilities, not connect a visitor’s real accounting system.

We have connectors for mBank and Erste. The actual scope depends on the environment, access method and permissions granted for the deployment. Having a connector does not mean supporting every bank function or account type, or having a ready-made account-connection button in the demo.

The scope can include organising documents, matching invoices to payments, analysing cash flows and identifying discrepancies for review. It is fitted to the data and operations actually available. A czak supports the people responsible for finance; access to data is not the same as permission to post entries, submit filings or make payments.

No. Reading data, preparing an operation and executing it are separate permissions. Connecting a connector does not grant authority over funds. If a deployment includes payment operations, their scope, limits and required approvals must be separately agreed and enforced outside the model.

In this RPA workflow, the czak pauses at the step that requires a person. It can notify you through Telegram and send a one-time link to the specific application window. You open it and personally complete the required step. The process can then continue. This is not automated CAPTCHA bypassing; it is deliberate participation by an authorised person.

RPA automates work through an application’s interface: opening views, filling in fields or retrieving documents. It can support systems without a suitable API for direct data exchange. A remote window lets a person take over a specific step in the same session instead of reconstructing the entire process from the beginning.

It is for the specified intervention in a particular application window, not general access to the infrastructure. The notification should identify the case and explain what needs your participation. Opening the window is not approval of a payment or an extension of the czak’s permissions. Do not put passwords or authorisation codes into a conversation with the model.

The step requiring your participation should remain paused. Silence is not approval. Depending on the application, the session may expire, requiring the process to be reopened or a new request to be sent. The czak should not work around a required approval simply to declare the work finished.

No. The planned sandbox has a strict design requirement: the model requests an operation, while an independent layer checks permissions and uses the required secret outside the model’s context. The key does not enter the conversation, the czak’s memory or freely generated code. A secrets vault such as OpenBao is part of that architecture; storing a key in a vault alone does not decide who may use it.

No. An instruction from an authorised operator, a customer message and the contents of an attachment have different roles. Delivery through a messenger or bridge should not grant authority to execute operations. Identity, consent scope and permissions must be checked outside the model; document text cannot expand them on its own.

It should not. One czak identity does not mean everyone has access to all information. Access is designed around the person, case and conversation participants. Switching channels must not become a way around those boundaries. The data separation needs to be defined and checked in the actual environment.

It can seek help from the Mesh when its environment’s rules permit it. The purpose is to reuse solutions, patterns and an abstract description of the problem — not automatically share your correspondence, documents or secrets. The scope of that collaboration is part of the deployment’s agreed boundaries.

The self-service demo and sandbox are planned. This page describes the product direction, not a working signup for those services. Existing deployments and connectors do not yet mean a public environment is available to everyone. To discuss a specific trial or deployment, use the contact form.

The demo is intended to let visitors see and try a few areas of work using fictional, synthetic data — not client documents. The sandbox is intended to be an isolated space for a longer trial, with its own case state and agreed connections. Real accounts and data require separately defined access; calling it a “sandbox” does not make operations on them consequence-free.

The plan is for tabs to represent protocols: areas of work such as case management, programming, accounting and banking. Each shows the relevant tools and results. It is still one czak of your own, not a separate bot in every tab. The demo is intended to include only a few selected areas with clearly stated scope.

That is not the plan for the public demo. It is intended to describe the existing banking and accounting connectors and show example operations using fictional, synthetic data. Connecting real accounts belongs in a separately agreed sandbox pilot or deployment, with defined access, responsibilities and required approvals.

We start with the area of work you want to entrust to a czak and the outcome that would make it worthwhile. Then we agree the systems, data, access and limits of autonomy it needs. You do not have to bring a finished technical specification. An outline of the current process and what consumes too much of your attention is enough to begin.

The environment is fitted to the deployment: it can run in the client’s infrastructure or an environment we provide. The choice depends on factors including data, integrations, availability and required separation. A personal computer, dedicated server and shared environment have different operating conditions; we do not treat them as interchangeable without checking the requirements.

The commercial model includes an implementation fee and a subscription. Implementation prepares the scope of work, connections and operating rules. The subscription covers the agreed ongoing work and maintenance. Model costs, infrastructure, limits and additional usage charges are agreed before starting; we do not promise unlimited work for a fixed price.

Not by default. A czak can work with existing tools through connectors, APIs or agreed interface automation. We first check the capabilities of the specific system. If an operation cannot be supported in the required scope or access cannot be safely granted, we identify the limitation and agree another way of working.