Agentic OS — how to automate a small company’s back office

The system uses one shared project. Thematic sections organize the chats inside it. Each chat defines a repeatable task: registering incoming invoices, preparing customer invoices, checking payment status, following up on sales opportunities or producing a weekly blog draft.

Some tasks run on a schedule, others on request. Both follow the same structure: shared business information, a persistent task definition, current inputs and a verifiable result.

Connectors provide access to email, SharePoint, Google Drive, Teams and CRM data. The file system and cloud storage hold working documents and pass results between tasks. This guide describes how to set up such a system and how its tasks work together. It follows a back office that runs this way at a small company.

What an Agentic OS is

Agentic OS is not a product but a way of looking at one. An AI assistant with projects, persistent instructions, scheduled tasks and connectors does for business work what an operating system does for programs: it holds shared state, runs programs on a schedule, talks to devices through drivers and enforces permissions. Many observers now describe the big providers’ platforms in these terms; the providers themselves name the parts differently.

Technically the platform is interchangeable. Claude, ChatGPT, Grok and others offer the building blocks — workspaces with persistent instructions, recurring tasks, integrations with other systems — under different names and to a different extent; what a platform can do today is worth checking before choosing it. A regular subscription to the assistant is enough. The architecture this guide describes does not depend on the choice.

Three levels: project, chat, execution

The architecture has three levels. The project holds what applies to every task. A chat holds one recurring task and its procedure. An execution is a single run of that task with the current inputs — started by a schedule or a request, carried out through connectors and local tools, and closed by a check of its result.

One project for shared business information

All tasks belong to one project and share a common operational foundation. The project contains business rules, document locations, templates, reference information, permissions and operating procedures. Thematic sections make the task chats easier to navigate:

The sections organize the work; the shared project information connects it. A contract can define billing conditions. Time records provide quantities. An invoice creates a payment obligation. A bank transaction records settlement. Different tasks handle these stages using the same underlying business information.

What to define at project level

Project-level instructions establish rules that apply across tasks.

Authoritative sources

Each category of information has a designated source:

• SharePoint holds registered documents and their attributes.
• The accounting checklist defines expected invoices and their frequency.
• Time-tracking lists contain recorded hours.
• Approved templates define document structure.
• The CRM holds commercial opportunities and next actions.
• The operational mailbox receives incoming correspondence.

Tasks read current information from these sources. Earlier documents and conversations provide context; the designated records determine the current operational state.

Business rules

Shared instructions define reporting periods, counterpart matching, invoice numbering, calculations, rounding, duplicate detection and what each status means.

For example, an invoice date and a service period are separate fields. Monthly, quarterly and annual invoices follow different allocation rules. Customer billing rates and contractor compensation rates are applied separately.

When a decision affects several tasks, it is added to the shared rules so that future executions use it.

Document organization

The project defines locations for originals, templates, drafts, approved documents and processing logs. New documents are created from copies of approved templates. Corrections produce identifiable versions. Downstream tasks use the specific approved file.

Permissions and completion criteria

The instructions define which actions each task is authorized to take. Preparing a draft, registering a document, sending an email and publishing content are separate actions, each with its own completion criteria.

A task reports success only after checking the result: the document exists, its attributes are correct, the generated file passes validation, or the sending operation has a confirmed record.

Each chat defines a repeatable task

Every operational chat represents a task that can run again and again. The chat holds its procedure, task-specific decisions, execution history, exceptions and results. A new execution supplies current parameters and applies the established procedure.

A customer-invoicing chat, for example, defines:

• where to obtain the hours;
• which activities to include or exclude;
• which rates and currency to use;
• which template to copy;
• how to select the billing period;
• how to validate and approve the result.

The user can then ask: “Prepare the invoice for the previous month.”

An invoice-registration chat follows a different procedure but uses the same shared counterpart information, document conventions and status definitions. Task-specific details stay with the task. Decisions that matter to other tasks are recorded in the shared project information. Files, registers and logs provide explicit handoffs between executions.

Task definitions and individual executions

Keep the persistent task apart from its individual executions. “Register incoming invoices” is a task; “process the files received this morning” is one execution. “Generate a monthly customer invoice” is a task; “generate the invoice for October” is one execution.

Each task definition covers:

Scheduled and requested executions use the same task definition. The trigger only determines when the task runs.

A correction to one invoice is a specific execution within the relevant task chat. If it reveals a reusable rule, that rule becomes part of the maintained instructions.

Connectors and their roles

The assistant’s desktop app is the place to work in, because it combines connected services with a local working directory on the computer:

Local tools support calculations, file conversion and validation where needed.

Connector access and business authorization are handled separately. A task uses the capabilities its procedure requires and the permissions established for its execution.

Complaica connects the same way, through its MCP connector. Compliance tasks such as keeping the record of processing activities up to date then run in the same project as finance and administration.

Shared storage also acts as a queue

The file system, SharePoint and cloud storage serve two purposes: storing results and passing them between tasks. Each task writes its output to an agreed location. A downstream task checks that location on its next run, identifies new items and processes them. Designated folders, document libraries and processing records therefore form a lightweight queue.

Invoice processing illustrates the arrangement:

1. A scheduled email check detects an incoming invoice.
2. It saves the attachment to the invoice analyzer’s input folder.
3. The invoice analyzer runs on its own schedule.
4. It reads, validates and registers the new invoice.
5. The document and its attributes are saved in SharePoint.
6. The monthly reconciliation checks the registered invoices against the accounting checklist.

The email task completes the intake stage once it has verified that the attachment was saved. The invoice analyzer discovers the file on its next run; processing records distinguish new, completed and partially processed items.

This allows tasks to run independently on different schedules. A saved result remains available until the next task processes it.

Finance: registering incoming invoices

The invoice-registration task checks its input folder at fixed intervals — every hour during the operating window, for example. Documents arrive as file submissions or through authorized email processing. The task:

1. finds new or partially processed files;
2. reads and classifies each document;
3. extracts the counterpart, invoice number, date, amount, currency and service period;
4. checks for duplicates;
5. registers the document in SharePoint;
6. writes and verifies its attributes;
7. updates the accounting checklist;
8. records the result.

Duplicate checks consider business identifiers and file content: the same invoice may arrive more than once or under different filenames. The log links the source file to the registered document and the checklist update.

If registration succeeds but the checklist update fails, the next execution resumes the unfinished step. The existing registration is retained.

Finance: checking completeness

The completeness task checks whether all expected invoices have been registered. The checklist defines regular counterparts, document frequency, expected timing and who is responsible for preparation.

At the beginning of the month the task compares these expectations with the documents saved in SharePoint. A later review checks the updated position before the accounting handover. Status markers summarize processing:

• R: registered;
• P: paid;
• S: handed over to accounting.

Combined markers show which stages are complete. If several invoices are expected for a period, one document does not establish completeness; partial results are explained with references to the underlying records.

Irregular expenses are checked after registration, without creating an expectation that another invoice must arrive every month.

The output identifies missing documents, unresolved periods and unfinished actions.

Finance: generating invoices

Separate task chats handle contractor invoices and customer invoices.

Contractor calculations can use hourly rates, fixed monthly amounts or compensation proportional to recorded working time. Support fees, additional hours and approved reimbursements appear as separate lines where required.

Customer invoices apply the agreed sales conditions. The task selects billable activities and excludes internal work according to the shared rules.

Each execution reads current data, calculates amounts, copies the approved template, assigns the document details and creates the working file and the PDF. Validation covers calculations and presentation: totals must reconcile, and the exported document must contain readable tables and complete details.

Drafting, user review, external approval and sending have distinct statuses. A revised calculation produces a new document version with its own approval state.

Finance: payments, reconciliation and reporting

Further tasks cover payment checks, bank reconciliation, verification in the accounting system and financial reporting:

• Payments. The payment task identifies registered invoices with outstanding payment actions.
• Reconciliation. The reconciliation task matches bank transactions to documents using identifiers, amounts, dates and payment references. Ambiguous matches remain open for review.
• Accounting verification. The internal document register is compared with the accounting records.

These tasks support updates to profit-and-loss reporting and the current cash position. Their rules keep invoiced activity, payment obligations and actual cash movements apart.

Unresolved items are reported with document references and the action or decision required.

Administration, contracts and time tracking

Administrative tasks process contracts, salary statements, tax documents, management accounting reports and correspondence. Each document category has a storage location, required attributes and a follow-up procedure.

Contract registration links a document to the relevant counterpart and captures the important dates. Shared contract details then support invoicing and sales follow-up.

Time tracking has its own recurring task. It reminds team members to complete their records and checks whether the information is ready for billing.

This makes a dependency explicit: invoice generation relies on sufficiently complete time records. Missing hours become a visible exception before a document is finalized.

Email intake and processing records

The email task checks the operational mailbox at short intervals, every five minutes for example. Messages enter a processing queue with stable identifiers. For each message the task records the sender, subject, processing stage, completed actions, related files, errors and outstanding decisions.

Authorized invoice attachments are placed in the finance input folder. Other messages are summarized with proposed next steps, within the task’s permissions.

Reports distinguish between an attachment being received, saved for processing and registered successfully.

Repeated executions check earlier results before acting. This prevents duplicate processing and repeated notifications about unchanged conditions.

Sales, marketing and product tasks

Sales tasks cover proposal generation, opportunity and contract follow-up, pipeline analysis and CRM maintenance. Proposal generation uses shared templates and commercial rules. Opportunity follow-up checks the next action, the expected response and approaching deadlines. Further tasks review customer developments and opportunities to expand cooperation.

Marketing tasks handle the analysis of tenders and freelance opportunities, campaign preparation, audience follow-up and recurring content production. A weekly blog task receives a topic and source material, prepares a draft and follows the agreed review procedure. Campaign preparation and sending have separately defined permissions and completion criteria.

The product section contains a backlog-maintenance task. It collects requests, identifies duplicates, improves descriptions and prepares items for prioritization.

All these tasks use the project’s shared business context and save their results where other tasks can access them.

Execution rules across the system

Every recurring task follows the same operating principles:

• Read current source data.
• Check whether the action has already been completed.
• Save outputs to the agreed location.
• Verify the result.
• Record completed and unfinished steps.
• Resume partial work on the next execution.
• Report new results, failures and required decisions.

The architecture gives each component a clear role. One project holds shared information. Thematic sections organize the chats. Each chat defines a repeatable task. Connectors provide access to working systems. Shared storage passes results between tasks. Schedules and user requests start executions.

This way the automation can grow one task at a time while the business rules, the processing history and the operational results stay connected.

Security and data protection

An assistant that reads mail, files documents and writes to business systems needs firm limits. Set these from the start:

• A separate account. The AI should work under an account of its own and reach exactly one of the company’s mailboxes — its own. In SharePoint and Teams the account gets only the libraries its tasks need, and no administrator rights.
• Internal senders only. That mailbox should accept mail from the company’s own staff and from no one else. An outside document, such as a supplier’s invoice, then reaches it only when an employee forwards it, so instructions hidden in a stranger’s message (prompt injection) never get to the AI.
• Confirmation before changes. A message can start a task, but the AI changes data only after a person has confirmed the change.
• Every change in git. Keep all files on the working disk in a git repository — on the company’s own Azure DevOps, for example — and commit every change. Who changed what, and when, can then be traced, and any earlier state can be restored.
• Employee data stays local. Let a script on the local machine fill in the payslips. Employee data then never has to be sent to the AI’s cloud.
• Documentation in Complaica. The record of processing activities under Art. 30 GDPR is created and kept up to date automatically in Complaica.

Internal mail only: the setting in Microsoft 365

In Exchange Online this is a property of the mailbox. In the Exchange admin center: Recipients → Mailboxes → select the AI’s mailbox → Mail flow → Message delivery restrictions, and under “Accept messages from” tick “Require senders to be authenticated”. The same in Exchange Online PowerShell:

Set-Mailbox -Identity ai@example.com -RequireSenderAuthenticationEnabled $true

From then on, mail from outside the organization is rejected with a non-delivery report — also when it forges an internal sender address, because the check rests on whether the sender has signed in, not on the address in the From line. To narrow it to named colleagues, -AcceptMessagesOnlyFromSendersOrMembers takes a list of users or a group.

Compliance work in the same pattern

Compliance work fits the same pattern. Complaica has a built-in MCP server and becomes one more connector in ChatGPT, Claude or another assistant. A task chat can then find gaps against ISO 27001, record evaluations or draft a DPIA — with your own sign-in, and every call runs with your roles and your licence.

Connect Complaica to your AI assistant