Appearance
FAQ
1. Automations and Agent-Based Execution
CZ otázka
Jak technicky funguje tvrzení, že CODEXIS AI pracuje agentně a umí samostatně plnit úkoly podle plánu?
CZ odpověď
CODEXIS AI podporuje automatizace, které spouštějí agenta ručně nebo podle harmonogramu. Každá automatizace obsahuje zejména název, popis, prompt, vybraného agenta, sadu skillů, pracovní adresář, limit počtu kroků a plán ve standardním pětipoložkovém Linux cron formátu. Při spuštění systém vyvolá vybraného agenta, předá mu zadané skilly a provede běh nad určeným pracovním adresářem.
Každý běh má vlastní historii a stav, například RUNNING, COMPLETED nebo FAILED, takže je možné zpětně dohledat, co automatizace udělala a s jakým výsledkem. Automatizace jsou ukládány odděleně pro každého uživatele v běhovém prostředí. Pokud by se nový časový trigger spustil v době, kdy předchozí běh ještě probíhá, systém nebuduje neomezenou frontu, ale drží maximálně jeden čekající běh. Tím se omezuje nekontrolované hromadění úloh.
Prakticky to znamená, že lze nastavit například noční zpracování dokumentů, pravidelné reporty, kontrolní workflow nebo opakované integrační úlohy bez nutnosti ručního spuštění.
EN question
How does the statement that CODEXIS AI works agentically and can execute tasks on a schedule work in practice?
EN answer
CODEXIS AI supports automations that launch an agent either manually or on a schedule. Each automation stores a title, description, prompt, selected agent, selected skills, working directory, step limit, and a schedule in standard 5-field Linux cron format. When triggered, the platform executes the selected agent with the configured skills in the defined working directory.
Each run has its own history and status, such as RUNNING, COMPLETED, or FAILED, so the execution remains auditable. Automations are stored per user inside the runtime environment. If a new schedule trigger fires while a previous run is still active, the system does not build an unlimited queue and keeps at most one pending run. This prevents uncontrolled backlog growth.
In practice, this covers scenarios such as nightly document processing, recurring reporting, control workflows, or repeated integration tasks without manual intervention.
2. Is Any Client Application Needed for Automations?
CZ otázka
Je pro používání automatizací potřeba instalovat nějakou aplikaci?
CZ odpověď
Pro samotné automatizace obvykle není potřeba instalovat samostatnou desktopovou aplikaci pro koncového uživatele. Automatizace běží uvnitř CODEXIS AI runtime, tedy v izolovaném virtuálním prostředí, kde je k dispozici agent, skilly, pracovní adresář i integrační nástroje.
Dodatečná instalace na straně klienta je potřeba pouze v případě, že součástí řešení má být přímá synchronizace firemních složek nebo napojení na lokální systémy. V takovém případě se na určený klientský nebo serverový stroj nasazuje synchronizační nebo integrační komponenta, nikoli samostatná aplikace pro každý jednotlivý pracovní notebook.
EN question
Is any application required in order to use automations?
EN answer
For automations themselves, an additional desktop application is usually not required for end users. Automations run inside the CODEXIS AI runtime, which is an isolated virtual environment containing the agent, skills, working directory, and integration tooling.
Additional software is only needed when the solution includes direct synchronization of company folders or integration with local systems. In that case, a synchronization or integration component is deployed on a designated client-side or server-side machine, not as a separate application on every employee workstation.
3. Direct Access to Client Files
CZ otázka
Jak technicky funguje tvrzení, že CODEXIS AI vidí soubory přímo v našem prostředí, umí je upravovat a ukládat zpět bez ručního nahrávání a stahování?
CZ odpověď
V aktuálním referenčním návrhu se tento scénář řeší přes synchronizační vrstvu. Na klientské straně a na serverové straně běží synchronizační služba, typicky Syncthing. Administrátor určí konkrétní firemní složky, které se mají synchronizovat. Tyto složky se následně přenesou na backendový server a tam se připojí do izolovaného virtuálního prostředí, ve kterém běží CODEXIS AI.
Pro agenta se pak synchronizovaná složka chová jako běžný pracovní adresář ve VM. AI může soubory číst, upravovat a ukládat zpět do stejného umístění. Změny se následně propagují zpět přes synchronizační vrstvu do klientského prostředí. Uživatel tedy neprovádí ruční upload ani download jednotlivých souborů.
Důležité je, že AI nemá automaticky přístup k celému firemnímu disku nebo síti. Přístup se omezuje na výslovně nakonfigurované a synchronizované složky, které jsou do runtime připojeny. To umožňuje řídit rozsah dat, se kterými může agent pracovat.
EN question
How does the statement that CODEXIS AI can see files directly in our environment, edit them, and save them back without manual upload and download work technically?
EN answer
In the current architecture, this scenario is implemented through a synchronization layer. A synchronization daemon, typically Syncthing, runs on the client side and on the server side. An administrator selects which company folders should be synchronized. Those folders are then replicated to the backend server and mounted into the isolated virtual environment where CODEXIS AI runs.
From the agent's perspective, the synchronized folder behaves like a normal working directory inside the VM. The AI can read files, modify them, and save them back to the same location. The resulting changes are then propagated back through the synchronization layer into the client environment. This removes the need for manual per-file upload and download.
The important security point is that the AI does not automatically gain access to the entire company disk or network. Access is limited to explicitly configured and synchronized folders that are mounted into the runtime.
4. Technical Detail for the File Synchronization Model
CZ otázka
Můžete poskytnout více technických detailů k přímé práci se soubory?
CZ odpověď
Ano. Referenční tok je následující:
- Na určeném klientském stroji nebo firemním serveru se nainstaluje synchronizační služba.
- Vybrané složky se synchronizují na serverovou stranu.
- Backendový server tyto synchronizované cesty připojí do uživatelské VM.
- CODEXIS AI nad nimi pracuje jako nad standardním adresářem ve svém sandboxu.
- Vytvořené nebo upravené soubory se vracejí stejnou synchronizační cestou zpět do klientského prostředí.
Tento model je vhodný tam, kde klient požaduje průběžnou práci nad firemní dokumentací, sdílenými složkami nebo dávkovými vstupy bez ruční manipulace s přílohami. Současně odděluje běhové prostředí AI od produkčního prostředí klienta a zjednodušuje auditovatelnost datového toku.
EN question
Can you provide more technical detail about the direct file access model?
EN answer
Yes. The reference flow is as follows:
- A synchronization service is installed on a designated client-side machine or company server.
- Selected folders are synchronized to the server side.
- The backend server mounts those synchronized paths into the user VM.
- CODEXIS AI works with them as standard directories inside its sandbox.
- Created or modified files return to the client environment through the same synchronization path.
This model is suitable when the client needs continuous work on company documents, shared folders, or batch inputs without manual attachment handling. At the same time, it keeps the AI runtime separated from the client's production environment and makes the data flow easier to audit.
5. VM Operating System
CZ otázka
Na jakém operačním systému běží virtuální prostředí CODEXIS AI?
CZ odpověď
Referenční virtuální prostředí běží na Ubuntu 25.10. Architektura je ale navržena tak, aby bylo možné použít i jiný Linuxový systém, pokud podporuje systemd. Praktickým požadavkem tedy není konkrétní distribuce jako taková, ale stabilní Linuxové prostředí se zapnutým systemd.
EN question
What operating system runs inside the CODEXIS AI virtual environment?
EN answer
The reference virtual environment runs on Ubuntu 25.10. However, the architecture can also operate on another Linux distribution as long as it supports systemd. In practice, the key requirement is not one specific distribution, but a stable Linux environment with systemd available.
6. Machine Parameters and Updates
CZ otázka
Jaké jsou technické požadavky na stroj a jak probíhají aktualizace?
CZ odpověď
Pevná univerzální hardwarová konfigurace není součástí této dokumentace, protože sizing závisí na konkrétním nasazení. Rozhodující jsou zejména počet souběžných uživatelů, počet a četnost automatizací, objem synchronizovaných dat, používané modely a požadované integrační konektory. Proto se finální CPU, RAM, disk a síťová kapacita stanovují podle cílového provozu klienta.
Aktualizace probíhají primárně centrálně na serverové straně. To obvykle znamená rollout nové verze backendu, frontendové aplikace, gateway vrstvy, pluginů a pomocných runtime komponent. Uživatelské definice, například automatizace a jejich historie, zůstávají uložené odděleně v uživatelském prostředí. Pokud je součástí řešení i klientská synchronizační služba, její update se plánuje samostatně, protože běží na klientem určeném stroji.
EN question
What are the machine requirements and how are updates handled?
EN answer
There is no single universal hardware profile in this document because sizing depends on the deployment scenario. The main drivers are the number of concurrent users, the number and frequency of automations, the volume of synchronized data, the selected AI models, and the required integration connectors. Final CPU, RAM, storage, and network sizing should therefore be defined for the target client workload.
Updates are handled primarily on the server side. In practice, this usually means rolling out a new backend version, frontend application, gateway layer, plugins, and supporting runtime components. User definitions, such as automations and their history, remain stored separately in the user environment. If the solution also includes a client-side synchronization service, that component is updated separately because it runs on a customer-designated machine.
7. Integrations with Other Systems
CZ otázka
Na jaké další aplikace a systémy se umí CODEXIS AI napojit?
CZ odpověď
CODEXIS AI je rozšiřitelný přes pluginy, agenty, skilly a MCP servery. Prakticky to znamená, že se může napojit na systémy, které poskytují API, příkazovou řádku, souborové rozhraní nebo vlastní integrační službu. Platforma umí pracovat s pluginovými nástroji, lokálními nebo marketplace skilly, aplikačními komponentami a konektory přes MCP transporty jako stdio, SSE nebo HTTP.
Typicky tedy lze připojit například interní knowledge base, DMS, ERP, CRM, ticketovací systém, sdílené úložiště, firemní API nebo jinou interní aplikaci, pokud pro ni existuje nebo se dodá příslušný konektor. Nejde pouze o pasivní čtení dat. Agent může pomocí těchto nástrojů provádět workflow kroky, spouštět integrační operace a vracet výstupy zpět do cílového systému.
Příklad: klient může mít plugin, který poskytne nástroje lookupCustomer, createTicket a postReport, k tomu synchronizovanou složku s dokumenty a skill pro interní metodiku. Automatizace pak každou noc spustí agenta, který přečte nové soubory, vyhodnotí je podle firemních pravidel, zapíše výsledek do ticketovacího systému a uloží report zpět do synchronizované složky.
EN question
What other applications and systems can CODEXIS AI integrate with?
EN answer
CODEXIS AI is extensible through plugins, agents, skills, and MCP servers. In practice, this means it can connect to systems that expose an API, command-line interface, file interface, or a custom integration service. The platform can work with plugin-provided tools, local or marketplace skills, application components, and connectors over MCP transports such as stdio, SSE, or HTTP.
Typical targets therefore include internal knowledge bases, document management systems, ERP, CRM, ticketing platforms, shared storage, company APIs, or other internal applications, provided that a suitable connector exists or is delivered. This is not limited to passive data access. The agent can use those tools to perform workflow steps, trigger integration actions, and write results back into the target system.
Example: a client can have a plugin exposing tools such as lookupCustomer, createTicket, and postReport, combined with a synchronized document folder and a skill containing internal operating rules. An automation can then run every night, let the agent process new files, evaluate them against company rules, write the result into the ticketing system, and save a report back into the synchronized folder.