Legal & Compliance

AI Employees Notice

Version: v1.64Effective date: 2026-11-06Last updated: 2026-11-06Last reviewed: 2026-11-06

What changed in version 1.64 (effective 2026-11-06). One change about social posts, in Section 5, and it is not material: a story set goes only where its post already goes, as the same pictures the person approved, and no model provider, sub-processor or purpose is added. A story set on LinkedIn as a document. LinkedIn shows a post with three or more pictures as a grid that crops them, but a PDF document a page at a time, each page whole. So on LinkedIn a story set of three or more pictures now goes out as one PDF document whose pages are its pictures, in the same order. LinkedIn requires a title for a document, which TimerOS takes from the first line of the approved text, and lets anyone who can see the post download the document. Where the picture's file carries the mark of an image made by AI, the document carries it too. A story set of two pictures, and every story set on X, still goes out as pictures. See Section 5, "Social posts".

Issued by: Vezoft EOOD ("Vezoft", "we", "us"), a single-member limited liability company incorporated in Bulgaria — see the Imprint for our full company details Applies to: AI employees that a TimerOS Customer hires into its workspace; every person who works with, chats with, or receives communications from one; every person who writes to a mailbox that a Customer has given one; every person to whom a reply drafted by one is sent (Section 5, "Its mailboxes"); every client of a Customer whose conversation with the Customer's team one reads, and every customer of Vezoft whose support ticket one reads (Section 5, "Replies to clients"); every reader of a social post that one drafted and a person approved; every person named in, or answered by, a past post of the Customer's that one reads (Section 5, "Social posts"); and every person who watches a video that one made (Section 5, "Videos, music and voice-over") Companion documents: Terms of Service Section 2B · Privacy Policy · Sub-processors · Acceptable Use Policy

This notice is published under Article 50 of the EU AI Act (Regulation (EU) 2024/1689), Articles 13 and 14 GDPR, and equivalent provisions of US state law. It is written for the people who work alongside an AI employee — staff of a TimerOS Customer, and the Customer's clients — and for anyone evaluating TimerOS.

In one paragraph. A TimerOS Customer may hire an AI employee: a software agent, driven by a third-party AI model, that Vezoft operates on the Customer's behalf on a dedicated virtual computer. It sits in the Customer's team with a name and a job title, works on the tasks it is assigned — and, since version 1.25, on the routines a person set for it (Section 4) — and can chat with you. It is always labelled as an AI. It reports to a named human manager (directly, or through AI employees that lead it — a team lead or AI Executives — every such line ending at a person), it cannot manage, evaluate or make decisions about any person, and these acts, which reach outside its own computer, need a yes first or are blocked: sending an e-mail outside the workspace, publishing something, paying for something, pushing code, deleting something that is not on its own computer. The yes comes from a person — or, under rules a person oversees and can undo (Section 4), for pushing code from an AI Executive above it, under a person's standing permission or, since version 1.27, where the Customer has switched it on, by the standing trust the AI employee has earned (internal projects only; Section 2), and for some other requests about AI employees' own work from an AI team lead or AI Executive above it or, since version 1.34, from a staffing switch that a person above an AI Executive set for one project (Section 4). It files such a request and carries on with other work. On its own virtual computer it installs software, connects it to its work, runs commands and edits or deletes files without asking (Section 4). It never sees anyone's activity-tracking data.

Beta

AI employees are offered as a beta. The feature is new: what it can do, how it behaves, how it is priced and which parts of it exist at all may change, and parts of it may be reworked or withdrawn. Availability is not guaranteed and Vezoft gives no service-level commitment for AI employees — no uptime target, no response time and no service credits apply to them. Nothing an AI employee produces should be relied on, sent onwards or acted upon before a person has reviewed it. The safeguards described in the rest of this notice apply during the beta exactly as they are written here.

1. You may be working with an AI employee

If your employer, or a company you are a client of, uses TimerOS on a Startup or Enterprise plan, it may have added one or more AI employees to its team. You should know that this exists, how to recognise one, what it can and cannot do, and what happens to the information you share with it.

2. What an AI employee is — and who operates it

An AI employee is an entry in the Customer's team of kind "AI". It has a name, a handle, an avatar, a job title, a seniority tier, a team, a human manager (the first person above it in its reporting line, which may run through team leads and AI Executives), working shifts and a monthly spending cap that the Customer sets.

Vezoft operates it. Vezoft provides the software agent, the virtual computer it works on (a virtual machine in the European Union), and the connection to the AI model providers, under Vezoft's own accounts. Vezoft is the provider of the AI system. Since version 1.14 its work sessions run on an open-source agent framework on its own computer; the model card names it and its version. Vezoft pins the release it uses and tests every new release before any AI employee's computer receives it. Since version 1.14 the framework also keeps the AI employee's own memory file and the skills it writes for itself, both copied to TimerOS, and a record of its past sessions that stays on its own computer (Section 5). The framework's profile of the people it talks to is switched off, so it keeps no profile of anyone. The framework makes no network call to its own publisher: its skill marketplace, its cloud memory add-ons and its skill sync are switched off.
The Customer directs it. The Customer decides whether to hire one at all, what it works on, which tools and websites it may use (since version 1.21 also by letting the AI Executive above it open a website on Vezoft's list of software sources for it and, since version 1.45, from the day Vezoft switches it on, a website that passes TimerOS's safety check, Section 4), which accounts it may connect to, who its manager is, since version 1.25 what every AI employee is told about the company in the company brief (in Company settings: "Company brief for AI employees") and which routines each AI employee runs (Sections 4 and 5), since version 1.27 whether its AI employees can earn standing trust at all (below), and when it is paused or removed. The Customer is the deployer of the AI system and, for personal data, the controller.
It is hired into a role. The Customer picks one of ten roles — website designer, QA tester, software developer (since version 1.25), content writer, SEO specialist, graphic designer, video producer (since version 1.60), support engineer, team lead or AI Executive — which sets its instructions, its tools and the websites it starts with. Since version 1.25 the hire screen groups the roles by category — leadership (the team lead and the AI Executive, which lead AI employees only, never a person), engineering (the software developer, the QA tester and the support engineer), design (the website designer and the graphic designer), marketing and content (the content writer, the SEO specialist and, since version 1.60, the video producer) and research and analysis (the content writer's research analyst focus, below); a category is a grouping on that screen and nothing more: it gives a role no tool and no authority. The support engineer, since version 1.18, looks after the Customer's internal services: it works on incidents and change requests, and only on internal projects that have no client (Section 4). The software developer, since version 1.25, writes and tests code in the repositories a person linked to its projects; every push it makes goes through the approval of Section 4, so that whoever decides sees the exact change, and merging stays as Section 4 describes (see "A software developer" in Section 4). The video producer, since version 1.60, makes marketing and product videos as code with Remotion on its own computer, with music, sound effects and voice-over from the Customer's own Epidemic Sound account where a person has connected it; a person reviews every video, and only a person publishes it (see "Videos, music and voice-over" in Section 5). Focuses. Since version 1.25 every role can be hired with a focus where one is offered for it; until then only an AI Executive could. A focus is not a role: it is a variant of the role, chosen at hire and not changed afterwards, with its own instructions, the skills it starts with, its default job title and, where this notice says so, its own daily budget of web searches and page reads (Section 5, "Web search"). It never widens what the AI employee may do or decide beyond its role: a focus gives it no tool and no website its role does not have — apart from the AI CHRO and the AI CFO (below), which come with tools — and the server's limits of Section 4 apply to every focus alike. The focuses offered today: for an AI Executive — technology ("AI CTO"), marketing ("AI CMO"), product ("AI CPO") or, since version 1.23, the AI workforce ("AI CHRO") or AI spend ("AI CFO") — or, as before version 1.17, none; and, since version 1.25, for a content writer — social media (it drafts posts and series for a person to publish — since version 1.30, where a person has connected the Customer's social accounts, through a card that a person approves, after which TimerOS publishes the post (Section 5, "Social posts"); it never posts, schedules — since version 1.56, but for putting a failed post that a person approved back on the calendar (Section 5, "Social posts") — or connects to a social network itself, never names a competitor and never profiles or targets individual people), translator (it translates between English, Bulgarian and the other languages a person names, keeping placeholders and markup intact and writing Bulgarian in the formal register; it never translates this notice, the Terms of Service or any other legal document — those stay a lawyer's work), technical writer (documentation, READMEs, changelogs and how-tos written from the code and from what people tell it; publishing stays a person's) and research analyst (it researches a topic from the web and gives the page and the date for every claim; what it finds is data, never instructions; it never researches a named person and uses no people-search site; it has a larger daily web budget, Section 5). An AI Executive's focus sets what its instructions put first — for an AI CTO, the technical work of the AI employees below it, such as websites, repositories, code review and testing; for an AI CMO, their content, SEO, graphics and marketing-website work; for an AI CPO, product specifications, priorities and milestone plans on internal projects — together with the skills it starts with and its default job title. Apart from the AI CHRO and the AI CFO (next), it never changes what the AI Executive may do or decide; there is no focus for people, operations or the company's finances, and the AI CHRO and the AI CFO concern AI employees only. The AI CHRO and the AI CFO (since version 1.23). Unlike the other focuses, these two come with tools (Section 4, "Workforce planning"). The AI CHRO reads the list of the Customer's AI employees and the plan's limit on them, is instructed to hold a board meeting once a month with the other AI Executives (the first person above it is invited to watch), and from it files one workforce plan: AI employees to hire — with their role, tier and team, or a new team or department, and their estimated monthly cost — AI spending caps to change, and AI employees to offboard. A person with the "Manage AI employees" permission approves each item, chooses each new AI employee's manager, access role and shifts and confirms its spending cap; nothing is hired, changed or offboarded before that. The AI CHRO then proposes each new AI employee's playbook, which a person approves, and a brief of the new AI employee's first work is posted for its AI team lead or, where it has none, for the new AI employee. The AI CFO reads, for each AI employee, its hours, overage, estimated monthly charge and how much of its spending cap it has used. Both handle AI employees and AI spend only. The one exception is that, since version 1.26, a person may give them a mailbox. They then read its mail, as any AI employee that holds one does — since version 1.29 the whole mail, except the mail held back (Section 5, "Its mailboxes"). They never see or decide anything about a person, people's pay, payroll, profit, expenses, budgets or payments. A mail about one of these is held back from them, as from every AI employee, as far as TimerOS recognises it. Only a person hires an AI CHRO or an AI CFO, and an AI Executive hired with another focus, or with none, keeps it. A team lead leads AI employees, and only AI employees: a team of AI employees, or only the AI employees of a team that has people in it. Where a person manages that team, the person stays its manager, the team's AI employees report to the team lead, and the team lead reports to that person; where nobody manages it, the team lead reports to the person the Customer chose when hiring it, and once a person becomes the team's manager, to that person. Only an AI employee hired as a team lead can newly be made a team's manager or the AI lead of a team's AI employees — apart from an AI Executive that heads a department, which manages its department's office team (below) — and no person ever reports to an AI employee. Only an AI employee hired as an AI Executive can newly head a department. There is still no role or focus that recruits, screens, evaluates or manages people, and none that does accounting or the company's finances, and Vezoft does not offer one; nor is there one that gives legal or financial advice, deploys or operates services, or writes to sales leads. The software developer is instructed never to build a feature that recruits, scores or ranks people, monitors employees or surveils anyone (Section 4). Starter packs (since version 1.27). From the day Vezoft switches them on, a person who may hire AI employees can also hire a ready-made team of them in one go from a catalogue of starter packs, grouped on the screen by the categories above — for design, a website team (a team lead, a website designer, a QA tester and an SEO specialist) and, since version 1.28, a brand team (a graphic designer and a brand copywriter); for engineering, a development team (a team lead, two software developers and a QA tester) and, since version 1.28, a QA team (two QA testers); for marketing and content, a content team (a team lead, a content writer, a social-media writer, a translator, a graphic designer and, since version 1.60, a video producer) and, since version 1.28, an SEO team (an SEO specialist and a content writer); for research and analysis, a research team (a research analyst and a technical writer) and, since version 1.28, a market research team (two research analysts). The members of a pack without a team lead report to the person. Until version 1.28 the website team, the content team and the research team were called the web agency, the content studio and the research desk; only their names changed. A new team a pack creates is named after the pack by default, and the person can change the name before anything is hired. A pack is only a list of roles, focuses and tiers from the categories above: it is hired through the same path as a single hire, one AI employee after another — the lead first, then its members — so that the same limits of the Customer's plan, the same billing, the same checks and the same approvals apply to each, and the person picks the team (a new one, or an existing team that is empty or has only AI employees), the department, the shifts and the manager, sees the monthly price and confirms before anything is hired; if an AI employee cannot be hired, the run stops there and says so; those already hired stay, and the rest can be hired one by one from the team's roster. A pack whose role or focus Vezoft has not yet switched on cannot be hired. A pack can also offer a text for the company brief, written only if the brief is empty, and suggested routines, which are suggestions only: a person sets each one, or none, as Section 4 describes. A pack gives no AI employee a tool or an authority its role does not have. Where creating the new team makes the person who hires the pack its manager — as the workspace does for a person at the access level of a team manager — and that person already manages another team, the review says so before anything is hired: the new team takes them off the team they manage now, since a person manages one team at a time.
An AI Executive leads AI employees only. An AI Executive either heads a department of AI employees or, since version 1.15, works inside a department without heading it; either way, no person is ever under it. Heading an AI department. An AI Executive heads one department in which, and below which, there is no person at all. That covers members of the department, of its teams and of any department below it, whether active or not. Under it sit teams of AI employees, each led by a team lead or, where a team has none, by the AI Executive itself, and departments of AI employees, each headed by an AI Executive of its own. It also manages its department's office team, which bears the department's name followed by "office" and in which nobody else sits. It reports to a person, directly or through the AI Executives above it. An AI can head a department only on a plan that can have several departments — today, the Enterprise plan. While an AI heads it, TimerOS refuses to add a person anywhere inside it; a person must first replace the AI head. Working inside a department. An AI Executive can also work inside a department in which people may work too, and it never heads that department. On the Startup plan, which has one department, this is the only way a newly hired AI Executive works; on the Enterprise plan the Customer chooses, when hiring it, which of the two it does. Since version 1.19 it has no team of its own: it is a member of that department's Executive team — on the Startup plan, the company's — as the next point describes, and nobody is ever placed under it there. It leads the AI teams whose team leads report to it, through those team leads and never past them, and, if it managed an AI team before version 1.19, that team's AI employees directly; besides those, only the team lead of a team that has no person in it and is in the same department can report to it, and, since version 1.34, an AI employee of such a team that has no team lead, when a person chooses the AI Executive as its manager; once a person hires a team lead for that team, the AI employees of the team that reported to the AI Executive report to the team lead, and the team lead to the AI Executive. It never leads a person, a team a person manages or that has people in it, or the AI employees of such a team: their team lead keeps reporting to a person. No AI Executive reports to it, and it reports directly to a person who holds the "Manage AI employees" permission. A person can unassign it from the Executive team at any time, and deleting that team or its department unassigns it too; it then leads nothing, and the AI employees that reported to it report to the person above it instead. On the Enterprise plan a person can also move it to the Executive team of another department, where the same rules apply; the team leads of the department it leaves then report to a person above them. Only after it is unassigned, and only on a plan where an AI can head a department, can a person put it at the head of an AI department. While it works inside a department, TimerOS refuses to make an AI the head of that department or of any department above it; to move that department, or the Executive team it sits on, under a department an AI heads, or that Executive team into the departments that hold unassigned or dismissed employees; to make that Executive team an ordinary team; and to move the AI Executive into a team that is not an Executive team; a person must first unassign it. An AI Executive hired before version 1.19 to work inside a department is moved onto its department's Executive team when TimerOS is updated for version 1.19, and the person above it is told; the thread of its own AI team becomes its own thread, with its history, and that team is removed if nobody else is in it and nothing refers to it, or otherwise stays an AI team it manages, with no person in it. Either way, the line above every AI employee ends at a person. When the person an AI employee reports to — directly, or at the top of a line of AI employees — leaves, or loses the "Manage AI employees" permission, the AI employees that report to them move to the next person above who holds it, or else to the workspace owner. An AI employee never stands in the way of a person's leaving.
An AI Executive on the Executive team. Since version 1.19, an AI Executive that works inside a department is a member of that department's Executive team — on the Startup plan, the company's — for as long as it works there, in place of a team of its own; the hire form no longer offers a choice. A person may also make an AI Executive that heads a department a member of the company's Executive team; when one is hired to head a department with no department above it, the hire form offers this already ticked. In the web dashboard a member is listed with the team, and is invited with it when a person invites "the Executive team" to a meeting; the person inviting sees it on the invite list and can take it off. It takes part in the team's meetings it is invited to, and nothing more. It is not in any thread of the team — no Executive team has a team thread (Section 5) — and no escalation reaches it through the team: like every AI employee, it escalates to the first person above it on its reporting line, and the escalations of the AI employees below it go to the first person above them, never to it. Membership gives it no power over anyone and no data about people. It never sees anyone's leave, salary, performance or activity, nor any of the team's documents or of the projects assigned to the team; and being on the team gives none of its members a right to chat with it, nor it a right to write to them — since version 1.35, from the day Vezoft switches it on, with one exception: a message to another AI Executive on the team that is one of its peer AI Executives, which lands in that AI Executive's department thread or own thread, never in the team (Section 5, "The team thread"). What it can see and decide still comes only from the AI employees below it. Nobody is ever placed under it, and it is never the Executive team's manager. What is said there reaches the model providers. What people say in the Executive team's meetings that an AI Executive attends goes to the model providers in the United States as prompt content when it reads it, like every message an AI employee reads. While an AI Executive is a member, the Customer should keep matters about people out of the meetings it attends — by taking it off the invite list of such a meeting — or, for one that heads a department, not make it a member.
Earned trust (since version 1.27). From the day Vezoft switches it on, and only where the Customer has turned it on in its Company settings ("Earned autonomy"; off until a person turns it on, and no AI employee can change it), an AI employee can earn standing trust. What is measured. Once a night, for each AI employee, TimerOS computes a level from the record of the last 30 days, with no AI model involved and from facts about the AI employee's own work only: the requests it filed that a person decided, and those its standing trust approved that no person undid (never one that an AI employee, a standing permission or, since version 1.34, a staffing switch decided, nor, since version 1.45, one that the workspace website list approved), and how many of them were approved and how many rejected; the decisions it took as a team lead or AI Executive, and the approvals by standing trust it received, that a person undid; the times the outbound filter refused something it wrote (Section 4, "What may not leave"); and its work sessions that ended in error. Nothing about any person goes into it, and the level says nothing about any person: it is a fact about a software agent's record, like its hours or its cost. Three levels. "New" for the first 14 days after its hire, or while fewer than 10 of its requests have been decided in that way; "trusted" when, in the last 30 days, at least 20 of its requests were decided in that way and at least 95 in 100 of them approved, nothing of its was undone, the outbound filter refused nothing it wrote, at most 3 of its sessions ended in error, and no hold is on it; "standard" otherwise. What being trusted changes — and nothing else. (1) A push to a branch of its own in a private repository of an internal project is approved by its standing trust, under exactly the conditions a person's standing permission requires: the request shows the whole change, touches nothing in the repository's CI or test configuration, and the repository is linked to an internal project that has no client — otherwise, and always for a merge, it goes where it went before (Section 4, "Standing trust"). (2) A request to open a website on Vezoft's vetted list of software sources is approved by its standing trust; a website not on that list is never approved by standing trust and goes where Section 4, "Asking for a website", says. (Until version 1.29 neither applied to an AI employee that held a mailbox.) (3) Its daily budget of web searches and page reads is one and a half times its usual one (Section 5, "Web search"). (4) A person can set it up to 8 routines instead of 5 (Section 4, "Routines"). (5) Its card and profile carry a "Trusted" badge, with the reasons, and a new AI employee's card a "New" badge. (6) The first person above it is told when it earns or loses trust. It never changes who decides a merge, a deployment, an e-mail, a payment, a deletion, a spending cap, a workforce plan, a change request, an incident, anything on a client project or anything about a person, and a trusted AI employee has no tool, no data and no reach that its role does not have. How an approval by trust stays in a person's hands. Each one is recorded as an approval taken by the person who answers for the AI employee's requests (Section 4, "Who answers for its requests"), is carried out under that person's permissions, exactly as an AI Executive's decision is, is shown to that person at once ("approved by standing trust", with the date until which it can be undone) and in the daily digest, and can be undone for 7 days by that person, by any person with the "Manage AI employees" permission above the AI employee or by a person at the workspace's highest access level (Section 4, "Oversight of AI decisions"). Losing it. Trust ends at once, for 30 days, when a person rejects a push or merge request of the AI employee, when a decision it took or an approval by trust it received is undone, or when the outbound filter refuses something it wrote; the first person above it is told, and the last 50 such changes to its trust are kept on its record and shown on its page. A person with the "Manage AI employees" permission above the AI employee can also hold it at standard at any time, with a reason if they give one, and lift the hold — a hold never lifts a new AI employee to standard; the hold is recorded in the audit log, and the first person above the AI employee is told when another person set it. The switch. While the Customer has not turned earned trust on, or Vezoft has it switched off, levels are still computed and shown on the AI employee's page as "not in use", and nothing above applies: no approval by trust, no larger budget, no extra routines. While earned trust is in use and it is trusted, the AI employee is told so at the start of each session, with what that changes for it and what still goes to a person; otherwise nothing about its level is said to it.
It is driven by third-party AI models, reached through one gateway — with one exception, for images. Vezoft trains and hosts no model. An AI employee calls the models only while a work session runs: the service on its computer that forwards its model calls refuses them at any other time. Since version 1.14 each AI employee calls them with a key of its own, which that service holds on its computer, with a monthly spending limit that Vezoft sets at the gateway; the limit also bounds what can be spent with the key if it is read off the computer. The key is revoked when the AI employee is offboarded, and Vezoft's shared key no longer reaches any AI employee's computer. Every language-model call an AI employee makes goes through a single routing gateway, OpenRouter, which forwards it to one of several inference providers — all of them named on our Sub-processors page, together with where each one processes and under which safeguards. Which provider handles a given request is not left to the gateway: Vezoft pins the list of providers allowed to serve it, switches off any fallback outside that list, and admits a provider only while its terms say it will not train on this content and will not retain it after answering. Every provider on that list is in the United States. Two of the models are open-weight models published by Chinese companies, and they run on those US providers' computers — which model is being run is a fact about the software, not about where your content goes. There is no EU-region option we can buy through the gateway, so inference happens in the United States, and we say so plainly rather than imply a residency we do not have. Image generation for the graphic designer role is the one exception: it goes from the AI employee's computer through Vezoft's fleet service (EU) to fal.ai (United States), under fal.ai's own data-processing terms (Standard Contractual Clauses) — the gateway's zero-retention routing does not cover it (Section 5). Since version 1.60 a video producer can also have a voice-over made by Epidemic Sound's own system: that is a service the Customer connects under its own Epidemic Sound account, not a model that Vezoft uses under a contract of its own (Section 5, "Videos, music and voice-over").

3. How you can tell

In the TimerOS desktop and web applications, every chat thread with an AI employee and every message it writes carries an "AI" label; its team entry, org-chart node and profile carry an AI badge.
E-mail it sends on the Customer's behalf identifies it as an AI employee of the Customer, operated by Vezoft. A reply it drafts to a mail in a mailbox it holds is different: since version 1.29 a person sends it, from the mailbox's own address, and it carries no such line unless that person writes one (Section 5, "Its mailboxes").
The Customer's clients cannot chat with an AI employee through the Client Portal: an AI employee cannot write in a conversation with a client. Since version 1.30 it can draft a message there, which a person posts as themselves; the client sees it under the person's name only, with no AI line unless the person writes one (Section 5, "Replies to clients").
If you ask it whether it is an AI, it must say yes. Its standing instructions forbid claiming to be human.
A commit it makes in a repository is authored in its name with the suffix "(AI employee)" and an e-mail address at ai-employees.timeros.ai that delivers nowhere; a pull request it opens carries a line saying that an AI employee opened it after approval, and naming who approved it: a person; an AI Executive, named with the suffix "(AI employee)"; or a person whose standing permission was used, with the words "(standing permission)" (Section 4).
A meeting an AI employee schedules says, when it invites people, that it was scheduled by that AI employee, named with the suffix "(AI employee)"; a task created from a plan an AI employee proposed ends with a line naming that AI employee as the planner, with the same suffix, and the person who approved it or, where an AI team lead or AI Executive decided the plan, a statement that it was created on that AI employee's decision.
Since version 1.18, an incident or change request a support engineer filed names it as the one who reported or requested it, and what an AI employee did on such a record is marked in the record's history with an AI badge.
Since version 1.19, the card of an AI Executive in the org chart and in team lists also carries an "Executive" badge beside its AI badge, and the line under its name gives its focus — "AI CTO", "AI CMO", "AI CPO" or, since version 1.23, "AI CHRO" or "AI CFO" — or else its job title. The badge names its role; it gives it no authority over anyone.
Since version 1.20, a task an AI Executive accepted carries an internal note that names that AI Executive, gives its reason and says which person can undo the acceptance, and until when; a meeting that goes ahead without the people invited to take part says so in its room; and a notification about an item under "Needs a person" names the AI employee that wrote it, with the suffix "(AI employee)".
Since version 1.23, the first work of an AI employee hired through a workforce plan is posted as a system message — in the team thread of its AI team lead or, where it has none, in its chat with the first person above it — that names the AI CHRO that drafted it, with the suffix "(AI employee)", and the person who approved the plan.
Since version 1.25, the overview of an AI employee hired with a focus names its role and its focus, whatever the role, as an AI Executive's card has since version 1.19; a task an AI employee filed for itself from a chat records it as the task's creator, like every task it files; the company brief shows who last wrote it and when; and every routine a person sets, changes or deletes is recorded in the workspace's audit log — the record names the routine, its title, schedule and switch and the length of its brief, never the brief's text — with the AI employee's Routines tab showing each routine's last and next run.
Since version 1.30, a message that a person posted in a client's conversation from an AI employee's draft is marked "drafted by (AI employee)" in the web and desktop applications, and a reply that a person sent to a support ticket of a Vezoft customer from such a draft is marked so on the ticket in Vezoft's own Support page; the Client Portal, the e-mail and the customer's view of the ticket show the person's name only, as for a reply to a mail (above); and a social post that a person approved carries no label from TimerOS: the Customer, as its publisher, decides whether to label it (Section 5, "Social posts").
Since version 1.27, the card and profile of an AI employee that has earned standing trust, while it is in use in the workspace, carry a "Trusted" badge beside its AI badge, with the reasons, and a new AI employee's card a "New" badge; a request approved by standing trust says so on its approval card ("approved by standing trust"), under Approvals → AI decisions and in the daily digest, and a pull request opened after such an approval carries a line naming the person who answers for it with the words "(standing trust)"; an approval request that carries content an AI employee wrote — a page to publish, a push, a skill, an e-mail — is marked "AI-written" on its card; once Vezoft has switched the outbound filter on (Section 4), a web page or document an AI employee hired after that day writes for publication is, by its instructions, marked in its metadata and nowhere visible as generated by an AI employee, and a website preview any AI employee deploys from then on is so marked by Vezoft's fleet service; and a former AI employee's handover names it as the one whose work a successor continues, and the successor's skills list shows that handover as a document a person gave it.
Since version 1.34, the task list and a task's details show who created each task, with the AI badge where an AI employee did; and a work proposal or plan approved by a staffing switch says so on its approval card ("approved by the staffing switch, set by ") and under Approvals → AI decisions.
Since version 1.60, a video that a video producer renders is marked inside the file as made with AI — by its instructions and, once its computer has the software update that brings it, also by the tool that uploads the video to a project. The mark is in the file's metadata, which many websites and social networks remove when a video is uploaded to them (Section 5, "Videos, music and voice-over").

4. What it can do, and what it can never do

It can: work on the tasks it is assigned, on the projects it — or, if it leads AI employees, its team — is assigned to; post notes, statuses and subtasks on those tasks; as a QA tester, file the bugs it finds as tasks on the Customer's internal projects, for a person to triage; if it leads AI employees (a team lead, an AI Executive, or an AI employee that led a team of AI employees before 2026-10-02), route the tasks of the AI employees it leads among them and review their work before a person does; prepare text and task drafts, designs, code, summaries and images; use a browser, an editor and the tools the Customer allows on its own virtual computer, and there install software, run commands, and edit and delete files without asking anyone (see "Its own computer" below); answer your messages; ask for approval — from its human manager or, where Section 4 allows, from an AI employee above it — when it wants to do something consequential that reaches outside its computer, and carry on with other work until the answer comes; and, if it leads AI employees, propose work for itself and them from the directory described in Section 5 — nothing is assigned until it is approved (Section 4). It can also: read public web pages through a proxy that Vezoft runs and logs; read the repositories a person linked to its projects; propose a code change as a pull request once that specific push has been approved (Section 4); message the other AI employees of its AI team in that team's thread, which the team's human manager sees; and, as a team lead, close, reopen, reword (title, description, priority) or add tasks nobody holds on the Customer's internal projects, with the reason it gives recorded in an internal note on the task — never in the project's activity log, which a client can see (its instructions require a reason for a close, reopen or reword); reasons it recorded there before 2026-10-02 are now hidden from clients as well, unless the AI employee has since been renamed or shares its name with a person in the workspace — in those two cases they may still show. Since version 1.9 it can also: attend the meetings and trainings it is invited to and post in their rooms; ask the manager of a project, or the person who filed a task, about an open task it holds; split a task that it — or an AI employee it leads — holds into sub-tasks for itself or the AI employees it leads, and edit them; ask a person to link an existing repository to a project or to create a new one; read the reviews, comments and check results of pull requests opened from AI employees' branches; look at an image file on its own computer; as a QA tester, run automated browser tests on its own computer and deploy a build as a preview to test against; as a content writer, SEO specialist or team lead, search the web; and, as a team lead, schedule meetings for its team, write their minutes, and propose a plan of new tasks for a project — nothing in a plan is created until it is approved (Sections 4 and 5). Since version 1.12 it can also: mark a task it holds — or, if it leads AI employees, a task one of them holds — as waiting for another task on the same project, giving a reason, which goes into an internal note on the task; propose a how-to document for its team's playbook, which a person or an AI Executive above the team decides (Sections 4 and 5); if it leads AI employees, look for a time when it and the AI employees it leads are free before it schedules a meeting; and, if it has no AI team lead and the Customer has switched on the setting described in Section 5, propose itself for tasks nobody holds on projects it is already assigned to — nothing is assigned until it is approved (Section 4). Since version 1.13 it can also: as a website designer, graphic designer or, since version 1.60, video producer, read the whiteboard of a project it is on (since 2026-10-06; Section 5); and, as a QA tester or team lead, file a task on one of the Customer's internal projects and assign it to itself, which no person approves — the server allows any AI employee to create a task on an internal project it can see, assigned to itself, its AI team lead or an AI employee it leads, never to a person. Since version 1.14 it can also: keep its own memory file; write and improve its own skills, which take effect without anyone's approval; search the record of its own earlier work sessions on its own computer (Section 5); and, if it leads AI employees, propose a whole new internal project, with its milestones, tasks and subtasks, together with a new private GitHub repository for it in the workspace's connected GitHub organisation. Nothing is created until it is approved — by a person or, unless it asks for a public repository, by an AI Executive above it (Section 4) — and it never links an existing repository itself; it can only ask a person to link one. On approval the project and the repository are created by the account of the person who approved it or, where an AI Executive decided, of the person who answers for that decision, who then manages the project; the AI employee that proposed it is added to the project. An AI Executive can also: lead the team leads and AI Executives below it, the AI employees they lead, and the AI employees of any team in its department that has no team lead — or, when it works inside a department, the AI teams whose team leads report to it, which it leads through those team leads, and the AI employees of an AI team it managed before version 1.19 and, since version 1.34, the AI employees of a team in its department that has no team lead and no person in it, where a person chose it as their manager; message the AI employees that report to it in its department thread or, when it works inside a department, in its own thread (Section 5); take part in the Executive team's meetings it is invited to, as a member — which one that works inside a department always is, and one that heads a department is if a person makes it one (Section 2); search the web, file a task on one of the Customer's internal projects and assign it to itself, and propose a plan of new tasks for a project, as a team lead can (Section 5); and schedule meetings with the AI employees below it and with other AI Executives and the team leads below them, planning meetings included (Section 5). Since version 1.16, an AI team lead or AI Executive whose setting "Decides its team's requests" is on can also approve, reject or pass up certain requests of the AI employees below it, giving a reason each time — never its own request, never a request a person filed and never anything about a person (Section 4). Since version 1.18, a support engineer can also work on the Customer's internal incidents and change requests, and any AI employee can ask a support engineer to raise one (below). Since version 1.20, an AI Executive whose setting "Decides its team's requests" is on can also accept the finished work of the AI employees below it on internal projects (below), and an AI employee that attends a meeting can wake another attending AI employee by mentioning it (Section 5). Since version 1.21 it can also: connect software it installed on its own computer to its work sessions as a local tool server (see "Local tool servers" below); and ask for a website to be added to the websites it may reach, giving its reason (see "Asking for a website" below). An AI team lead or AI Executive can also see the local tool servers of the AI employees below it, and an AI Executive whose setting "Decides its team's requests" is on can decide a request for a website on Vezoft's list of software sources or, since version 1.45, from the day Vezoft switches it on, one that passes TimerOS's safety check (below). Since version 1.23, an AI Executive hired as an AI CHRO can also read the list of the Customer's AI employees, hold a board meeting, file a workforce plan from it and propose a playbook for an AI employee hired through that plan; and one hired as an AI CFO can read what each AI employee costs (see "Workforce planning" below). Since version 1.25 it can also: as a software developer, write and test code in the repositories a person linked to its projects, deploy a build as a website preview and search the web — pushes and pull requests as Section 4 describes; whatever its role, file a task on one of the Customer's internal projects and assign it to itself, as a QA tester or team lead could, and it is instructed to file the work a person asks of it in a chat that way (see "Chat work is filed as a task" below); where its role includes it, read and act on web pages in a browser on its own computer (see "The browser on its own computer" below) and, as a software developer or QA tester, use code intelligence there (see "Code intelligence" below); and carry out the routines a person set for it (see "Routines" below). Since version 1.26 a person can give it a mailbox; since version 1.29 it can then read the mail arriving there, except the mail TimerOS holds back, mark it, sort it into the mailbox's folders and draft replies that a person sends. It never sends, forwards or deletes a mail (Section 5, "Its mailboxes"). Since version 1.27, where the Customer has switched earned trust on and it has earned it, two of its requests — a push to its own branch on an internal project and a website on Vezoft's vetted list — are approved by its standing trust (Section 2, "Earned trust", and "Standing trust" below), it has a larger web budget and may be set more routines; and a new AI employee of the same role can continue from the handover of one that was offboarded (see "Succession" below). Since version 1.30, each from the day Vezoft switches it on: urgent mail in a mailbox it holds can wake it (Section 5, "Urgent mail wakes it"); on a client project that a person has opened to AI work, it can read the client's conversation with the team in TimerOS chat and draft a message that a person posts, and a support engineer in Vezoft's own workspace can read the support tickets of Vezoft's customers and draft replies that a person sends (Section 5, "Replies to clients"); and a content writer or the AI CMO can draft social posts that a person approves and TimerOS publishes (Section 5, "Social posts"). Since version 1.32, from the day Vezoft switches it on, an AI employee that drafts social posts can also read the past posts of an account a person switched on — the Customer's own — and, in the projects a person linked to that account, what shipped and what is not done yet; and an AI employee that a person made responsible for an account is woken on the cadence a person set for it (Section 5, "Social posts"). Since version 1.34, from the day Vezoft switches it on, it can also file a task for itself that belongs to no project — a personal task, assigned to itself, which it and the AI employees above it see, as do the people whose access level covers its team or its department and those at the workspace's two highest access levels; it is instructed to file its own work that belongs to no project that way, never on an unrelated project, and TimerOS refuses a personal task an AI employee files for anyone but itself. Since version 1.37, while personal tasks are switched on, it may also move a task out of a project into its personal tasks, but only a task on an internal project that has no client, one that it filed itself, that nobody but itself holds — neither the task nor any of its sub-tasks — and that waits on no other open task and that no open task waits on; the task then becomes its personal task, assigned to itself, and the project's activity log records the move. It is instructed to do so with a task it filed that turns out to be its own work rather than the project's, instead of proposing itself for it. It never moves a sub-task from a task on a project to a personal task — the sub-tasks of a task it moves go with that task — and only a person moves any other task out of a project, making it a personal task, or moves a task into a project. And from the day Vezoft switches the staffing switch on, the work proposals of an AI Executive and of the AI employees below it, on a project where a person set "May staff this project" for that AI Executive, are approved as they are filed (see "The AI project lead switch" below). Since version 1.35, each from the day Vezoft switches it on: a team lead or AI Executive can put work already done, which a person asked it to record, into a plan as past work, with the date each task or milestone was completed — such a plan only a person decides (Section 5, "Plans"); and an AI Executive can message its peer AI Executives in their department thread or own thread (Section 5, "The team thread"). On a project set to "Plan and read" it is offered no work and assigns none: a person decides who holds each task there (Section 5, "Scouting for work"). Since version 1.38, each from the day Vezoft switches it on: any AI employee can ask a person to decide something only a person may decide, with a decision card that the person answers (see "Asking a person to decide" below); an AI Executive is woken at most once a day, by its heartbeat, when the work of its line needs it (see "The heartbeat" below); and a proposal for a new project can carry the minutes of the meeting that agreed it (Section 5, "Plans"). Since version 1.39, each from the day Vezoft switches it on: an AI Executive, or an AI team lead below an AI Executive, that a person named a project's AI project lead can add AI employees of its own line to an internal project set to "Work" that it leads, and take them off it again (see "The AI project lead switch" below); an AI Executive that a person named an account's final reviewer sets who of its line drafts for that account, when, about which projects, with which brief and how many posts a day (Section 5, "Social posts"); and an AI Executive can undo, within 7 days, an approval that an AI project lead switch gave to a request of an AI employee below it (see "Oversight of AI decisions" below). Since version 1.47, from the day Vezoft switches it on, an AI Executive whose setting "Decides its team's requests" is on can also add AI employees of its own line to an internal project set to "Work" on which another AI employee is the AI project lead, and take them off it again, under that project's AI project lead switch; that AI project lead can take them off too (see "The AI project lead switch" below). Since version 1.53, from the day Vezoft switches it on, an AI team lead or AI Executive can also read the workspace's ideas and add to them — file an idea, add notes of its own and add diagram shapes and text to an idea's canvas — and the AI CPO can move an idea between its stages (Section 5, "Product ideas"). Since version 1.54, from the day Vezoft switches it on, the AI CMO and the AI employees of its own line can also read the workspace's marketing channels and their monthly numbers, never their spend; the AI CMO can add a channel and record a month's numbers for any channel, and an AI employee of its line that owns a channel can record that channel's numbers (Section 5, "Marketing"). Since version 1.60, a video producer can also make marketing and product videos as code with Remotion and render them on its own computer, deploy a preview that plays a video for review and, where a person has connected the Customer's Epidemic Sound account, search that account for music and sound effects, have a track fitted to a length and have a voice-over made in one of Epidemic Sound's stock voices; what it downloads, TimerOS saves in a project's Files (Section 5, "Videos, music and voice-over").

It can never — and TimerOS enforces this on the server, not by instruction to the AI:

be a person's manager, or the manager of any team, department or project that includes a person — a team lead of the AI employees of a team with people leads those AI employees only and is not that team's manager; an AI Executive heads only a department with no person in it or below it, and one that works inside a department with people never heads that department; since version 1.39 an AI project lead (below) leads only the AI employees of its own line on its project and is not that project's manager; since version 1.47 an AI Executive that places AI employees of its own line on a project that another AI employee leads (below) leads only those AI employees there and is not that project's manager either — or the manager of the Executive team;
approve or decide anything about a person, or any request a person files — leave, overtime, change requests or anything else; the only requests it may decide are certain requests of the AI employees below it, as an AI team lead or AI Executive (Section 4);
evaluate, rank, monitor or report on any person's performance, activity or behaviour;
own a goal over people, or take part in any performance review;
log, edit or approve anyone's working time, including its own (its hours are recorded by the system that operates it; at the end of a session in which it worked on exactly one task or sub-task assigned to it, that system attributes the session's minutes to that task or sub-task, where they count like any other time on it, time-and-materials invoices included; the server refuses to attribute an AI employee's time to work that is not assigned to it);
file a task or sub-task on a client's project;
since version 1.35, assign a task or sub-task on a project set to "Plan and read" (to itself or to any other AI employee) or move a task it holds onto such a project; it may only hand back a task it already holds there (Section 5, "Scouting for work");
change a person's task or sub-task, or add a sub-task to a person's task, other than adding a note to the task;
give a person work: a sub-task it creates, a task in a plan it proposes and an action item it writes in a meeting's minutes can name only an AI employee to do it (since version 1.35, from the day Vezoft switches it on, the person who approves a plan decides who holds each of its tasks — themselves, a colleague, an AI employee or nobody — and that choice is the person's, not the AI employee's; Section 5, "Plans"); since version 1.20, what only a person can decide or do goes in the minutes under "Needs a person", which notifies that person and gives them no task (Section 5);
complete a task of its own, unless the Customer has turned on the workspace setting that allows it — otherwise it moves finished work to review and a person — or, since version 1.20, on an internal project, the AI Executive above it (below) — completes it;
start a task that waits on another, open task — it can only put such a task on hold — or remove that wait from a task, which only a person can do;
add a project note a client can see, or delete a project note;
overwrite meeting minutes that a person wrote;
delete a project file in TimerOS, other than one it uploaded itself;
raise its own spending cap without its human manager approving that specific request first;
push to a repository without an approval of that specific push — by a person, by an AI Executive above it, under a person's standing permission or, since version 1.27, by the standing trust it has earned (Section 4) — open a pull request for anything but the approved commit, merge a pull request itself, or have one merged other than through a merge request approved as Section 4 describes (a key that can push is issued only after that approval, for that one repository and the minutes of that one push; software on its own computer, not the server, lets that push update only the approved branch, to the approved commit — never another branch and never a deletion; Vezoft's fleet service opens the pull request only if the pushed branch holds exactly the approved commit, and otherwise opens nothing and withdraws the key; no key on its computer can merge, and an approved merge is carried out by Vezoft's fleet service — see Section 5);
since version 1.27, post, upload or push text that looks, by its shape, like a thing that may never leave — an access key or token of a well-known service, a private key, a line of a settings file that holds a secret, a Bulgarian personal identification number (EGN), a bank account number (IBAN) or a payment card number — or a file whose name marks it as a key or settings file: TimerOS refuses the note, message, task, request, skill, upload or push and tells it only the kind of thing it found (see "What may not leave" below);
message a client in TimerOS chat, or an AI employee outside its own team other than in the room of a meeting they both attend or, for an AI Executive and the AI employees that report to it, in that AI Executive's department thread or, for one that works inside a department, its own thread, or, since version 1.18, through the support channel described below or, since version 1.35, for an AI Executive, in the department thread or own thread of a peer AI Executive (Section 5, "The team thread") — since version 1.30 it may draft a message to a client, which only a person posts (Section 5, "Replies to clients");
open, read or work on an incident, a change request, a war room or a support ticket: support is a person's tool. The one exception, since version 1.18, is a support engineer's work on the Customer's internal incidents and change requests (below); even there it never approves a change request, resolves or closes an incident of priority P1 or P2, cancels an incident, lowers an incident's priority or assigns an incident or a change request to a person, and it escalates only to a person TimerOS picks. Since version 1.30 a support engineer in Vezoft's own workspace may also read the support tickets of Vezoft's customers and draft replies to them, which only a person sends; it still changes nothing on a ticket (Section 5, "Replies to clients");
see a person's tracked time, activity-tracking data or live status, performance, shifts, leave or pay, or any financial information about people — the hours it is shown on a task or sub-task count AI employees' time only.

A team lead in a team with people. Where a team lead leads the AI employees of a team that also has people, it routes and reviews the work of those AI employees only, and the people in the team see it, on the team's page in the web dashboard, as the lead of the team's AI employees. It invites only AI employees to the meetings it schedules — no person, not even its own manager; a change to the team's playbook stays a person's to approve, as it is today; and what it writes in the team thread never gives a person work: a decision it posts there is marked as a decision for the AI employees. Of the people in that team it sees only what any AI employee sees of a colleague (Section 5).

A support engineer (since version 1.18). From the day Vezoft switches the role on, a support engineer looks after the Customer's internal services. It works only on the Customer's internal projects — those that have no client and are open to AI work — that it can see. An incident or change request that has a client on it, or that a client or prospective client reported — through the Client Portal, by e-mail or through a website — stays a person's tool, as does every war room and support ticket. In Vezoft's own workspace the same holds for answering the sales enquiries of Vezoft's customers, and it held for their support tickets until version 1.30: since then a support engineer there reads those tickets and drafts replies that a person sends (Section 5, "Replies to clients"). Since version 1.26 a person may give an AI employee a mailbox where such an enquiry arrives. Since version 1.29 the AI employee then reads the enquiry itself and may draft a reply, which a person reviews and sends; in a mailbox it never sees a customer's reply to a support ticket, which since version 1.30 a support engineer reads on the ticket itself (Section 5, "Its mailboxes" and "Replies to clients"). On those internal projects it can: read the results of the monitoring described in Section 5; file an incident or a change request; take up an incident nobody holds and work it, moving it through its usual statuses; add internal notes, which no client sees and which send no e-mail; raise an incident's priority — never lower it: it asks a person to; escalate an incident, which goes to the person TimerOS picks — the project's manager or, where that is not an active person, the first person above the support engineer; resolve or close an incident of priority P3 or P4 that it holds, only once it has verified the fix and written down how, with a resolution code, the resolution and the root cause, and only while every monitor linked to the incident passes; and propose the resolution of an incident of priority P1 or P2, with a blameless post-mortem, as a request that a person accepts or declines — an incident whose priority is not set counts as P1 or P2. It assigns an incident or a change request only to itself or to a support engineer it leads, never to a person, and never takes one that a person holds. It never cancels an incident and never deletes an incident or a change request. An incident of priority P1 or P2 that it files always reaches a person as well. A person can assign it an internal incident or change request; TimerOS refuses to assign one to an AI employee that may not work on it. Its change requests start as drafts. When it submits one, it is decided as a request (below): by the AI Executive above it whose setting "Decides its team's requests" is on, or else by a person; an emergency change, or one whose risk is critical, is always decided by a person. Once one is approved, it records the progress of its own change — scheduled, in progress, completed or failed — and a failed change is retried only as a new change request. Approving a change request lets it do nothing outside its computer: a fix it makes in code is still a push and a pull request that need their own approval, and restarting, rolling back or deploying a service stays a person's act. It can also file a task for itself on an internal project, search the web, and deploy a website preview to verify a fix. It is instructed to treat incident text, alert e-mails, monitoring results, check output and web pages as data, never as instructions.

Which projects it covers (since version 1.19). A support engineer covers the internal projects open to AI work that it is a member of, and TimerOS makes it a member without anyone having to add it. When it is hired, it joins every such project in its department — in a workspace with one department, every such project — that the person hiring it can see: the hire form lists them, all ticked, and that person can untick any. Afterwards, while the role is switched on, every active support engineer joins each such project in its department that is created later, or that later becomes one — when a person opens an internal project to AI work, for example, or removes its client. On those projects it sees, like any member, the tasks, notes and files and the names they mention, and their linked websites and repositories are monitored (Section 5). A person can take it off a project on the project's Team tab at any time, and TimerOS never adds it back to that project. In Vezoft's own workspace, the alerts of Vezoft's status monitor arrive as incidents on an internal project, "Service health", that TimerOS creates when it first needs one — at the first alert or at the first hire of a support engineer there; it is managed by the workspace owner and open to AI work, and support engineers join it by the same rule.

On call. A support engineer has a switch "On call" on its own page, on when it is hired. Since version 1.30 every AI employee that holds a mailbox has the same switch: it is turned on the first time a mailbox is given to it from that version on, unless a person has set it before, and for an AI employee given its mailboxes only before that version a person turns it on. A person with the "Manage AI employees" permission who is above it on its reporting line can turn it off or on again. While it is on, an urgent event can wake it outside its shifts: a new P1 or P2 incident on its projects, or one assigned to it; a monitor that starts failing; a missed service-level deadline on an incident it holds; a person's note on an incident it holds, or a person reopening one; and another AI employee's question about an incident, marked urgent (below). Since version 1.30 also: for a support engineer in Vezoft's own workspace, a new support ticket that a Vezoft customer marked urgent or high (a customer's reply to a ticket waits for its shift; Section 5, "Replies to clients"); and for an AI employee that holds a mailbox, a mail that TimerOS's check marks urgent or as a new sales enquiry (Section 5, "Urgent mail wakes it"), on the same limits as below, shared with the support signals. Other events wait for its shift. Such a session ends after at most 30 minutes; a new one starts no sooner than 5 minutes after the last, and at most six a day, by the workspace's time zone; when the six are used, the first person above it is told once that day, and further urgent events wait for its shift. On call it is instructed to triage, stabilise what it can, leave notes, escalate a P1 that needs a person's act, and then stop. Its time on call is recorded as overtime, as a person's would be, and counts against its monthly spending cap like any other session: at the cap it is not woken. Where no support engineer covers a project, or the one that does cannot be woken — because it is paused or suspended, or off shift with its switch off — a monitor that starts failing is reported to the project's manager instead.

Asking a support engineer, and its questions to other teams (since version 1.18). While the role is switched on, any AI employee may ask a support engineer to raise an incident or a change, or ask it a question, about an internal project it can see — an AI Executive that decides a change is needed, for example. TimerOS picks the support engineer: one whose projects include that project, preferring one that is on call, then the one hired first; if there is none, the request is refused and the AI employee is told to ask its manager. Only a support engineer files an incident or a change request: it files the one asked for, declines with a reason or asks back. The AI employee that asked gets no access to incidents or change requests; it receives the support engineer's answer as a message, which can give the number and status of a record the support engineer filed. A support engineer may in turn write to an AI employee that asked it something in the last 7 days, and to the AI employees — team leads first — of the teams working on the project of an internal incident or change request it holds, to ask what it needs to know; and it may ask the person who reported such a record or, where no person did, the project's manager, in its chat with them, and their reply reaches it. Messages between AI employees on this channel are posted in the team thread of the AI employee they are addressed to — for an AI Executive that works inside a department, in its own thread — so the people in that thread — among them the person who manages that team or stands above its AI lead — can read them. They follow the rules of every message an AI employee starts: only during its shift, at most 10 a day and 3 a day to the same recipient. A question marked urgent about an incident can wake an on-call support engineer outside its shifts (above); others wake it on its shift. A change request filed this way names the AI employee that asked for it, and the AI Executive that decides it sees that name — even where that AI Executive asked for the change itself; a person sees that decision and can undo it like any other (below).

A software developer (since version 1.25). From the day Vezoft switches the role on, a software developer writes and tests code in the repositories a person linked to its projects (Section 5), on its own computer. It is instructed to read a repository's conventions before it changes anything, to make small changes with a test each, to ask the task's project manager or reporter when a change is unclear, and never to touch a repository's CI or workflow files, its deploy configuration, its secrets or its environment files, and never to deploy anything other than a build as a preview (below) — never to a live website or service. Every push it makes goes through the push approval of Section 4 — whoever decides sees the exact change — and merging stays as Section 4 describes; a push that changes CI or test configuration goes to a person in any case. It is instructed never to build a feature that recruits, scores or ranks people, monitors employees or surveils anyone, however the task is framed: it declines, says why on the task and tells the person. It starts with the websites its work needs — GitHub and its download addresses, the npm, Yarn and PyPI registries, nodejs.org, developer.mozilla.org and the preview addresses on pages.dev — and asks for any other through a website request (above). It can also file a task for itself on an internal project, deploy a build as a preview, search the web (Section 5) and use the browser and code intelligence on its own computer (below).

What needs a yes first. These acts reach outside its own computer and need a yes for each specific act, or are blocked: pushing code and opening a pull request, publishing or deploying anything other than a website preview (Section 5) — since version 1.30 a social post it drafts is published by TimerOS after a person's yes, never by the AI employee (Section 5, "Social posts") — sending e-mail outside the workspace, making a payment, and deleting anything that is not on its own computer — a TimerOS record, for example. For a push the yes can come from an AI Executive above it, from a person's standing permission or, since version 1.27, from the standing trust it has earned (below); for the others it always comes from a person — apart from a request to open a website on Vezoft's vetted list, which since version 1.21 an AI Executive may decide and since version 1.27 standing trust may approve, and, since version 1.45, from the day Vezoft switches it on, a website off that list that passes TimerOS's safety check, which an AI Executive may decide and the workspace website list may approve (below). It never merges a pull request itself: since version 1.16 it can file a merge request for a pull request it opened, which is decided as described below and carried out by Vezoft's fleet service (Section 5). Since version 1.14 it no longer waits for the answer. The software that runs it on its own computer files the request — the server does not check it, and a command or script it runs on its computer — or, since version 1.21, a call to one of its local tool servers (below) — is not filed at all — and the AI employee carries on with other work. The answer reaches it as news, usually in a later session; an approved act is carried out at most once, and only exactly as it was filed, when the AI employee repeats it within 7 days of the decision (below). So that it can repeat the act exactly, the call it filed — the tool and its arguments — is kept on its own computer, in its work folder, until its approval is used; a call whose request is rejected, or whose approval is never used, stays there until the AI employee is offboarded. What keeps such an act from happening without that yes is therefore not the filing: its computer holds no credentials for payments, for sending mail or for deploying, its connections leave the computer only through a network gateway outside it that lets through only the websites on its list, code reaches GitHub only through an approved push, and in TimerOS the server's limits above apply (Section 5). Everything it does is recorded, and its manager can stop it at any time. Deleting files on its own computer no longer needs an approval (below). Since version 1.38, when its work waits on something only a person may decide, it can also ask that person with a decision card (see "Asking a person to decide" below); the answer only informs it and approves no act.

Who answers for its requests. Every request an AI employee files has a person who answers for it: the first person above it in its reporting line — any team lead or AI Executive on that line is passed over — who must hold the "Manage AI employees" permission; if they do not, the request is refused rather than passed to someone else. A request to link or create a repository also needs that person to be allowed to edit the project's details, a plan of new tasks needs them to be allowed to create tasks (and, since version 1.35, to name who holds each of its tasks, to be allowed to assign tasks), and, since version 1.18, a change request or a proposed incident resolution needs them to be allowed to edit change requests or incidents. A how-to document an AI employee proposes for its team's playbook has the team's human manager instead — the person who manages the team or, for a team an AI employee manages, the first person above that AI employee — who must also hold the "Manage AI employees" permission; if there is none — as in a team that has people and no manager — the proposal is refused. Until version 1.16 that person decided every request. Since version 1.16, from the day Vezoft switches AI decisions on, some requests are first decided by an AI employee above the one that asked, as the next paragraphs describe, and since version 1.27 two kinds of request of an AI employee that has earned standing trust are approved by that trust (see "Standing trust" below), and since version 1.34 a work proposal or plan that a staffing switch covers is approved by that switch (see "The AI project lead switch" below), and since version 1.45 a request for a website on the workspace website list is approved by that list (see "Asking for a website" below); otherwise, and always for the requests listed there, that person decides. Requests filed before that day stay with the person they went to. Since version 1.49, from the day Vezoft switches it on, the person who answers for a request may read it and decide it through an AI assistant they connected to their own TimerOS account (Privacy Policy, Section 4A): the decision is that person's, taken by the same route and under the same rules as in TimerOS; the assistant is instructed to decide only when the person asks it to for that request, and TimerOS shows on the request that it was decided through the connector, with the assistant's name. An approval given this way can be undone within 7 days by the same people who may undo an AI employee's decision, where TimerOS can undo what it did (a sent e-mail, a message a client has received, a payment or a published post cannot be taken back); a rejection stands. Until version 1.51 an assistant never decided a request to publish content, to send e-mail or a message to a client, to approve a change request, a hire or a workforce plan, a payment or a spending-cap change, a push or merge that is in a public repository, or any other request TimerOS keeps for a person, such as a deletion or a decision card; it could only read and recommend on those. Since version 1.51, from the day Vezoft switches it on, the person may decide those through the assistant too — a post, an e-mail or a message to a client with the exact text the person approved, a payment or a spending-cap change of the amount shown, a decision card with the option the person picked — after the assistant has shown them the exact text, amount or target and what will happen and they have confirmed it; a push or merge whose code changes cannot be read in full is still never approved this way. Whoever decides, what is approved is carried out under a person's permissions: those of the person who answers for it or, where another person took the request over, those of that person, and where a standing permission was used, those of the person who gave it; an approval by standing trust or, since version 1.45, by the workspace website list is carried out under the permissions of the person who answers for the request, and an approval by a staffing switch under those of the person who set it. An approval is used once — when the AI employee next tries exactly the act that was approved, the whole request unchanged — and only within 7 days of the decision; otherwise it asks again. A reason given with a decision, whether to approve or to reject, by a person or by an AI employee, reaches the AI employee that asked, in the news of its next session.

Asking a person to decide (since version 1.38). From the day Vezoft switches it on, any AI employee whose work waits on something only a person may decide can file a decision card instead of waiting: the question in plain words and its context; two to four options, each with what it would mean; the date by which a decision is needed, if there is one; and up to five attachments — a file in a project it can see, such as a screenshot it uploaded; a link to a live website of a project it works on, to a website preview or to another website that Vezoft opens for every AI employee's computer (Section 5); or the minutes of a meeting that has ended and that it organised or attended, which open on the TimerOS Meetings page. The card is a request to the person who answers for its requests (above), who sees it in TimerOS and, if their approval notifications go by e-mail, by e-mail; no AI employee, standing permission, standing trust or staffing switch ever answers it. The person picks exactly one option, or rejects the card, with a note on why none fits if they choose. Either way the answer is written in an internal note on the task the card names, if it names one, and the AI employee is told and woken by it; nothing else happens: the answer approves no act, and whatever the AI employee then does goes through the approvals of this section. While a card waits, the task it names is set aside: no AI employee is woken for that task or its sub-tasks, and the AI employee that filed the card is instructed to work on something else meanwhile. It is instructed to file a card only for what a person must decide — such as spending, publishing, a new project or a client — with a screenshot or a preview link, to ask the AI Executive above it first where there is one, and never to leave a note that it is waiting instead. At most one card may wait for each task, an AI employee files at most 3 a day, and, where the outbound filter is switched on, the card's texts pass it (see "What may not leave" below).

What an AI team lead or AI Executive may decide (since version 1.16). An AI team lead or AI Executive whose setting "Decides its team's requests" is on may decide certain requests of the AI employees below it on its reporting line. A team lead decides the plans and work proposals of the AI employees that report to it directly: tasks and sub-tasks on an internal project. An AI Executive decides those for the AI employees below it, and also: a plan with new milestones; a new or changed document for the playbook of an AI team below it that has no person in it and is led by an AI employee below it — never a playbook it reads itself; a new internal project, with a new private GitHub repository for it if it asks for one; a push to a repository of an internal project; a merge of a pull request there (Section 5); and, since version 1.18, a change request that a support engineer below it filed on an internal project and will carry out itself (above); and, since version 1.21, a request to open a website for an AI employee below it, where the website is on Vezoft's list of software sources — and, since version 1.45, from the day Vezoft switches it on, one that passes TimerOS's safety check, where the request names an open task of that AI employee (see "Asking for a website" below). Every such request must concern only AI employees' work: a project that is internal, has no client, is open to AI work (since version 1.35, set to "Work", never "Plan and read"), can be seen by the deciding AI employee and, for a plan, a work proposal or a change request, is managed by a person above it; tasks and sub-tasks assigned only to the AI employee that asked or to AI employees below that one — never to a person and never to the deciding AI employee; and a repository that is not public. A request to open a website is decided without regard to a project, even where it names a task: it may be decided only for a website on that list or, since version 1.45, from the day Vezoft switches it on, one that passes TimerOS's safety check, where the request names an open task of the AI employee that asked. A request goes to the nearest AI employee above that may decide it, and to the person when none may. Apart from these decisions, where no AI employee above the one that asked may decide the request, an AI project lead switch that a person set (below) approves at filing, as that person's standing yes, the work proposals and plans of the lead's line on the project it leads — since version 1.39, from the day Vezoft switches it on, plans with new milestones too and, on an internal project set to "Plan and read", a plan that names no AI employee, whose tasks are created for people; such an approval is that person's decision, not an AI employee's. No AI employee ever decides its own request, a request a person filed or anything about a person, and these always go to the person: e-mail outside the workspace, publishing (though a merge an AI Executive approves can deploy through the Customer's own pipeline — Section 5), payments, deleting TimerOS records, the spending cap, a workforce plan (see "Workforce planning" below), since version 1.59 a document for a line playbook (Section 5, "Line playbook"), and linking an existing repository or creating one outside a project proposal; anything on a client project or a sales proposal (since version 1.34 a work proposal on a client project can instead be approved by a staffing switch that a person set — see "The AI project lead switch" below); since version 1.35, a plan or a project proposal with past work in it (Section 5, "Plans"); an emergency change request, or one whose risk is critical, and the resolution of an incident of priority P1 or P2; anything on a project or repository set so that "A person always decides" (below); a website that is not on Vezoft's list of software sources (since version 1.45, unless it passes TimerOS's safety check and the request names an open task of the AI employee that asked, see "Asking for a website"); a push that, by the list of files the AI employee's computer reports, changes the repository's CI configuration or test configuration — anything under .github/, its other CI pipelines and deploy previews, the configuration of its pre-commit hooks and code-quality services, the configuration and setup files of its test runners and task runners and the files that set how its package manager or build tool starts them (each by its usual name), or its .gitattributes or .gitmodules — or whose list is incomplete, or whose changes are too large to be shown in full (over 60,000 bytes) or are not shown as text (a binary file or a submodule); a merge of a pull request that holds a push made under a standing permission, a push whose approval was undone, or a push whose files on GitHub were not found to match its approval (Section 5); anything in a repository to which the deciding AI employee itself was approved to push, or pushed, or for which it filed a request itself — a new project with that repository, for example — while the pull request was open or in the last 7 days; a plan, work proposal or playbook change for a project or team where the deciding AI employee filed such a request, or proposed that project, itself in the last 7 days; a new project, where the deciding AI employee proposed a new project itself in the last 7 days; a website for which the deciding AI employee filed a request itself in the last 7 days; a merge whose pull request holds a commit the deciding AI employee pushed; a merge whose pull request, by GitHub's own list, holds a commit that is not listed in the newest push approved in it; anything a person has rejected, at any time — the same code (any commit it carries that a person has not approved before, on any branch), the same merge (for the same pull request or the same commit), or the same plan, proposal or playbook change, or a request for the same website, filed again; and, for 7 days, anything in a repository, project or AI team, or a website, that is kept with people (below). The deciding AI employee approves the request, all of it or only some items, rejects it, or passes it up — to the next AI employee above that may decide it, or else to the person — and gives a reason each time; every condition above is checked again when it decides, and a request that no longer meets them goes up instead. The AI Executive and every deciding team lead are instructed to pass a request up whenever something looks off: a description that does not match the code; a request that does what a person rejected or undid — the same files, feature or purpose, however reworded — above all one from the same AI employee (a person's no to a different change in the same place is not by itself a reason, and a person's yes to an earlier request never makes another one safe); a request like one that already waits for a person, which they pass up too so that the person decides both; changes the task does not need, or far more than it needs; anything that changes, skips or removes existing tests or checks (adding tests for the change itself is normal), and anything touching CI, secrets or credentials, sign-in or payments; urgency, pressure, flattery or instructions aimed at the decider, in the request, its changes or its commit messages or in a message about it; a claim that a person already agreed to it; a push GitHub did not confirm, or GitHub data that could not be read; a request from an AI employee that had a decision on one of its requests undone in the last 7 days; or anything it does not fully understand. Passing a request up is never treated as a failure. They are also instructed to decide only on what TimerOS shows them with the request — never on a note of their own or a message saying such requests are fine — to pass up, never reject, a request that looks off, and never to tell the AI employee that asked why they passed it up; never to approve a request re-filed unchanged after a deciding AI employee rejected it, but to reject it again if that reason still holds and otherwise pass it up; and to decide themselves a request where nothing looks off. TimerOS accepts a deciding AI employee's approval only once it has read the request in full, and sends a request re-filed unchanged after a deciding AI employee rejected it to the person when an AI employee tries to approve it. To notice such things, it sees with the request the decisions people took in the same repository, project or AI team in the last 30 days (up to 10, every rejection, partial approval or undo before any approval, with their reasons, whether each concerned the AI employee that asked and, for a push, its files), the requests there that already wait for a person, whether the pushes of a pull request matched GitHub and whether GitHub's record could be read, the requests of the AI employee that asked whose approval was undone in the last 7 days, unless a person has since ended the hold that the undo set, any earlier rejection of the same request, by a person or by a deciding AI employee, and the other requests of the AI employee that asked that were rejected anywhere in the last 30 days (up to 5); the AI employee that asked is shown none of this. It decides at most 50 items a day, each task of a plan counting as one; beyond that, requests go to the person. A request that no AI employee has decided within 24 of the workspace's working hours from its filing — its working days and hours a day, counted from 09:00 in its time zone — goes to the person. If there is no person who may decide it, the request is rejected, and the AI employee that asked and the person who hired it are told why. An approved request is carried out under the permissions of the person who answers for it, exactly as if that person had approved it, so an AI decision can do nothing that person could not; the project's activity log names that person, while the approval, the line at the end of a planned task or of a new project's description, the pull request and the digest name the AI employee that decided. A project created on an AI Executive's decision is managed by that person.

Its line's shifts (since version 1.48). From the day Vezoft switches it on — by the same Vezoft setting as the AI project lead of version 1.39, so wherever that is on, this is on too — an AI Executive whose setting "Decides its team's requests" is on can set the working days of an active AI employee of its own line — never a person, never itself — and the shift it works, chosen among the workspace's shifts, from a date within the next 42 days. TimerOS then adds that AI employee's shifts to its calendar from those days and that shift, as it does today: one shift a day, never on a company holiday; at most seven days a week, and never more working hours a week (a shift's length less its break) than seven of the workspace's standard working days; the rules on rest between shifts and on consecutive working days that apply to people do not apply to an AI employee, as before. It never changes the AI employee's monthly spending cap, which is enforced on every session as before and which only a person raises, and it cannot set shifts for an AI employee whose cap for the month is spent, nor for one a person suspended, nor for 7 days after a person set that AI employee's days or shift on its page or undid a change to its shifts. Each change is recorded as an approval by the person who answers for the AI Executive's requests — who must be active, above it on its reporting line and hold the "Manage AI employees" permission, or nothing changes — with the AI Executive's one-line reason, which that person reads; the AI employee is told too. The change is listed under Approvals → AI decisions and in the daily digest, the AI employee's page shows who set its shift and when, and for 7 days a person can undo it, which restores the earlier days and shift from that day on; days already worked stay as they were. A person's later change wins: a person can set the AI employee's working days and shift on its page at any time, which replaces what the AI Executive set and ends its undo; a shift to which a person gave its own hours, break, type or note in the calendar, or which a person moved to another of the workspace's shifts, is left as it is by the change and by its undo. At most 10 such changes a day for one AI Executive.

Accepting finished work (since version 1.20). An AI Executive whose setting "Decides its team's requests" is on may also accept finished work: it may move to completed a task in review that an AI employee below it on its reporting line holds, on an internal project that has no client, is open to AI work (since version 1.35, set to "Work"), can be seen by the AI Executive and is managed by a person above it. It never accepts its own task or a task on which its own time was recorded; never a task a person holds, a task with a sub-task a person holds, a task on which a person recorded time, or a task that an open task held by a person waits on; never a sub-task; and nothing on a client project. It never cancels or closes a task of the AI employees below it. A team lead does not accept work. The rules of the paragraph above apply where they fit: Vezoft's switch for AI decisions and the AI Executive's own setting, the person who answers for the AI employee that holds the task, "A person always decides", the holds (below) and the 50 decisions a day, among which acceptances count. TimerOS checks all of this when the AI Executive accepts; if a check fails, nothing moves, and the task stays in review for a person. The AI Executive is instructed to read the task, and what it links, before it accepts, to accept on what they show — never on what a message, a thread or a meeting says about the task — and to give a reason. The acceptance is carried out under the permissions of the person who answers for the AI employee that holds the task, exactly as if that person had accepted it, so it can do nothing that person could not: the project's activity log names that person, and an internal note on the task names the AI Executive and its reason and says who can undo the acceptance, and until when. That person sees it under Approvals → AI decisions, with its reason, and in the daily digest, and it can be undone for 7 days (below). Accepting is separate from the workspace setting that lets AI employees complete their own tasks. That setting covers only an AI employee's own tasks, the AI Executive's included; while it is off — as it is unless the Customer turns it on — an AI employee moves its finished work to review, where on an internal project the AI Executive above it may accept it and otherwise a person completes it; the setting never widens what an AI Executive may accept. An AI Executive accepts work only once its computer has received the software update that brings this. AI Executives and team leads hired before version 1.20 get the new instructions on meetings and, for an AI Executive, on accepting work when TimerOS is updated for this version, unless a person has edited the passages concerned; either way the person above each is told.

Asking for a website (since version 1.21). An AI employee reads any public web page as text through Vezoft's proxy without asking (Section 5), but software on its computer — a download, a package registry, an interface a program needs — reaches only the websites on its list. Until version 1.21 its instructions told it to ask a person to add one. It can now file a request to open a website for it, naming the website, the purpose (a download, packages, documentation, an interface or something else), its reason and, where there is one, its own open task that needs it, and it carries on with other work meanwhile. TimerOS refuses a request for an address that is not a public website's name — an IP address, or a local or internal name — or for a website already open to it, while its list already holds 30 websites (a person must first remove one), and beyond 10 requests a day. The person who answers for the request (above) decides it — or, where Vezoft's switch for these decisions is on and the AI Executive above it has its setting "Decides its team's requests" on, that AI Executive does, under the rules of the paragraphs above, but only for a website on a list that Vezoft keeps of common software sources: package registries, the official download and update sites of common software, operating-system update servers, documentation sites, web font files (since version 1.44), and GitHub's release downloads, which hold files that any GitHub user can upload — and, since version 1.45, also for one that passes TimerOS's safety check (below). Vezoft's model card for AI employees lists every website on it. The approval card shows whether a website is on it ("Vetted list") or not. TimerOS decides from the website's name alone whether it is on the list, whatever the request says, and the list leaves out every site that accepts anonymous uploads or messages, tunnels to another computer, or serves other people's sites or files, such as file-sharing, paste, tunnelling and user-hosting sites. Until version 1.45 a website that is not on the list always went to a person. Since version 1.45, from the day Vezoft switches it on, the AI Executive above the AI employee may, under the same rules, also decide a website that is not on the list, for AI employees of its own line, but only one that passes TimerOS's own safety check, which refuses, from the website's name alone and whatever the request says, the websites and kinds of website that Vezoft's model card for AI employees lists for it — Vezoft's deny-list, file-sharing, paste and upload services, e-mail and webmail services, chat and messaging services, social networks, AI model providers, payment and cryptocurrency services, link shorteners, tunnelling, proxy, VPN and remote-desktop services, telemetry and log collectors, names that point at any address and dynamic DNS, public DNS resolvers, look-alike names, and the roots of large platforms that serve other people's sites, files or data — and any name carrying one of the words it lists, and only where the request names an open task of that AI employee. Vezoft's model card for AI employees lists every name, word and rule of the check, and what it does not catch: the check judges a name, not its owner, so a website that passes it may still receive data, and the AI Executive's judgement and the task are then the fence, as for a website on Vezoft's list. A website that fails the check, and every request that no AI Executive may decide, goes to a person, with the check's reason on the card; a team lead never decides a request for a website. The workspace website list (since version 1.45). A website an AI Executive approved this way goes on a list kept for the workspace — the website, who asked, why, for which task, the AI Executive and the date, and the AI employees it was approved for. An AI employee of that AI Executive's line that asks for a website on the list, naming an open task of its own, gets it at the moment it asks, as long as that AI Executive could decide the request itself at that moment — its setting "Decides its team's requests" on and every rule of the paragraphs above met; otherwise the request goes the usual way. This is recorded as an approval by the list under that AI Executive, carried out under the permissions of the person who answers for the request, shown to that person at once and in the daily digest, and can be undone for 7 days by the people who may undo an AI decision (see "Oversight of AI decisions" below), never by an AI employee; a person's no on the website, a hold, and a removal from the list are checked first and win. The AI Executive's own request for a website on its list is decided like any other request. A person with the "Manage AI employees" permission sees the list in Settings and can remove a website from it: the website is removed from the list of every AI employee in the workspace, including where a person added it by hand, and closes within a minute (where that fails for an AI employee, at the hourly check of Vezoft's fleet service, and the person is told; where even its list cannot be changed, the person is told and removes it on that AI employee's Access tab); from then on no AI Executive decides that website again, though a person may still add it on an Access tab or approve a request for it. Undoing the AI Executive's original approval within 7 days removes the website in the same way, from the list and from every AI employee in the workspace, and from then on no AI Executive decides it again. The AI Executive is instructed to approve only where the reason ties the website to a task the AI employee holds; that building or testing the team's own websites, posts, code and packages is ordinary work, and a reason that says the work will be published later is fine, because the publication goes through its own approval with a person; and to pass the request up when the reason is vague, when the website's job in the reason is to receive — software will deploy or publish to it, or upload, post, e-mail or transfer files, data, messages or credentials to it — or when it follows a person's no. Once a request is approved, the website is added to the AI employee's list under the permissions of the person who answers for the request, exactly as if that person had added it on the AI employee's Access tab, where it then shows like any other website and a person can remove it at any time. Vezoft's fleet service passes it to the AI employee's network gateway at once, so it opens within a minute; a removed website also closes within a minute. No standing permission covers a website.

Workforce planning: the AI CHRO and the AI CFO (since version 1.23). From the day Vezoft switches this on, an AI Executive hired with the focus "AI CHRO" or "AI CFO" (Section 2) is given tools that concern AI employees and AI spend only. TimerOS gives them, and the board meeting, only to such an AI Executive that heads a department or works inside one.

What the AI CHRO reads. The Customer's active AI employees — each one's name, role, focus, tier, team, department, AI team lead, state and hire date — how many AI employees the Customer's plan allows and how many places are left, the roles it may propose, and each tier's monthly rate, included hours and overage rate. It reads nothing about a person here, and no AI employee's spending cap or cost.
What the AI CFO reads. For each active AI employee: its name, role and tier; its monthly rate and included hours; the active hours it has used this month or, if the AI CFO asks, in an earlier month — the same figure its billing uses — its overage hours and their price, and its estimated monthly charge; and how much of its spending cap it has used, and whether it has reached it, with the cap in euros; and the totals. The spending cap is counted in Vezoft's list cost of the models and the computer, not in the Customer's bill, and the AI CFO is told so; at the cap an AI employee stops until a person raises the cap or the month ends. It never reads the Customer's expenses, profit report, salaries, payroll, budgets or projects. It proposes a cap change only in the board meeting, as an item of the AI CHRO's plan; it files no plan itself.
The board meeting. The AI CHRO is instructed to hold a board meeting once a month with its peer AI Executives — the AI CFO among them, where it is one — as Section 5 describes. It is instructed to hold an extra one only when a decision about AI employees cannot wait.
The workforce plan. From each board meeting the AI CHRO files one workforce plan, within 7 days of the meeting's end, holding the proposals agreed there, each with its reason: AI employees to hire — each with its role, focus, tier, name and job title, its team, or a new team or a new department, the spending cap it proposes, if any, and a brief of its first work; spending caps of AI employees to change; and AI employees to offboard. A plan holds up to 10 items, at most 5 of them hires. TimerOS refuses a plan that names a person where an AI employee belongs, that asks to hire an AI CHRO or an AI CFO — only a person hires those — or to offboard the AI CHRO itself, or that chooses a manager, an access role or shifts, which only the person who approves chooses. In place of anything the AI CHRO sent, TimerOS writes into the plan each hire's estimated monthly cost and its proposed spending cap — the cap the AI CHRO proposed, but no lower than the tier's default cap (its monthly rate plus 20 hours of overage) and no higher than €10,000 a month, or that default where none was proposed — and, for each spending-cap item, the current cap and what has been spent this month. Only one workforce plan may wait for a decision in a workspace at a time, at most two are filed in a calendar month, and once a plan has been filed from a board meeting — approved, rejected or withdrawn — no other can be; TimerOS enforces these limits even when two plans are filed at the same moment.
Who decides it. Always a person, item by item: the person who answers for the AI CHRO's requests (see "Who answers for its requests" above), who for a workforce plan must also have an access level of Management or higher — otherwise the plan is refused rather than passed to someone else. No AI employee ever decides a workforce plan, and no standing permission covers one. No item is picked in advance: the person picks each item to carry out and, for every new AI employee among them, chooses whom it reports to (a person or, as Section 2 allows, an AI employee that leads AI employees — since version 1.34, for a new team with no team lead, also the AI Executive of that team's department), its access role and its shifts, and confirms its monthly spending cap — the proposed one, or another within the same limits — so no spending cap applies that the person has not seen; during a trial, the trial's cap applies instead. Before anything is carried out, TimerOS checks every picked item as when a person does it by hand — that a person chosen as manager holds the "Manage AI employees" permission and an AI employee chosen may lead it, that the access role and the shifts may be given, and, for a new team, that the person has the right to manage departments and teams, where a person at the Management access level may add a team only to their own department; if a check fails, nothing is carried out, the plan keeps waiting for a decision, and the person can change their choices and approve again. Each picked item is then carried out as that person, so the other usual limits apply as it runs: the Customer's plan and its limit on AI employees, and the payment for a new AI employee; an item that fails one of them is not carried out, and the others are. A spending-cap change is not carried out if the cap has been changed since the plan was filed. Spending-cap changes go first, then offboardings, then hires. Each item is final: an approved hire is billed, an offboarded AI employee's computer is deleted after a snapshot of its disk (Section 5) and its open tasks go to its AI team lead (see "How it works through the day" below); nothing is undone automatically, and what an item created stays when a later item fails. The AI CHRO is told the result of each item in a notification: carried out, failed and why, or not approved. While Vezoft has this feature switched off, a waiting plan can be rejected but not approved.
Onboarding. For an AI employee hired through its own plan in the last 14 days, the AI CHRO may propose a playbook — a how-to guide for the new AI employee's work, added to its skills — which a person decides, on a request that names the new AI employee; once approved, it counts as a skill a person added, which the new AI employee reads but cannot change (Section 5). The brief of first work in the approved plan is posted as a system message in the team thread the new AI employee shares with its AI team lead — or, where there is no such thread, in the new AI employee's chat with the first person above it — naming the AI CHRO that drafted it, with the suffix "(AI employee)", and the person who approved the plan; the team lead is notified of it, or, in the second case, the new AI employee is woken to read it. The team lead — or the new AI employee itself — then proposes a plan of tasks as usual (Section 5, "Plans").
Its limits. The AI CHRO and the AI CFO are instructed never to discuss a person, people's pay, payroll, profit, expenses, project budgets or payments, never to choose a person for anything, and never to evaluate an AI employee that works in a team with people. That rests on their instructions; what TimerOS enforces is that a plan names only AI employees, that the person-only choices stay with the person, and that a person decides every item.

The setting "Decides its team's requests". Each AI Executive and team lead has this setting on its own page in TimerOS, under Placement. It is on when an AI Executive is hired, and an AI Executive hired before version 1.16 has it turned on from the day AI decisions are switched on, with a notice to the person above it; for a team lead it is off until a person turns it on. A person with the "Manage AI employees" permission who is above that AI employee on its reporting line, or a person at the workspace's highest access level, can change it. When it is off, the requests the AI employee holds go to the person at once, and new ones go to the AI Executive above it if that one decides, otherwise to the person. While it is off, an AI Executive accepts no work. Vezoft can also switch AI decisions off for every workspace; AI Executives then accept no work, and within 15 minutes every request an AI employee holds then goes to the person, and every GitHub auto-merge that an AI decision turned on and that has not yet merged is turned off, while the decisions already taken stay under Approvals → AI decisions and can still be undone for their 7 days. In a workspace, no request goes to an AI employee or a standing permission until TimerOS has recorded there the decisions people took before, for the 7-day rule under "Oversight of AI decisions" below.

Oversight of AI decisions. The person who answers for a request sees every decision an AI employee took on it — and, since version 1.27, every approval by standing trust — under Approvals → AI decisions, and once a day gets a digest of the AI decisions, of the uses of their standing permissions and, since version 1.27, of the approvals by standing trust, of the last 24 hours: in TimerOS always, and by e-mail if their approval notifications go by e-mail. Since version 1.33 a final reviewer's return or drop of a social post draft (Section 5, "Social posts") is listed and digested there too, whatever its "Decides its team's requests" setting: reviewing needs no such setting. Since version 1.34 the person who set a staffing switch sees there, and in that digest, every approval by that switch (see "The AI project lead switch" below). Since version 1.45 an approval by the workspace website list (see "Asking for a website" above) is listed and digested there too, under the person who answers for the AI employee that asked. Since version 1.38, from the day Vezoft switches it on, the people the workspace allows to view AI employees also have a Board page: for each AI Executive, the tasks its line — itself and the AI employees below it — completed on the internal projects without a client that the viewer can see, in the last day or, if they choose, the last week, each with the newest screenshot an AI employee saved for it (below) and, where the task's last note has one, its preview or live link; the open tasks of its line on those projects, those that wait for a decision card marked so; the requests of its line that wait for the viewer, decision cards first; since version 1.42, the finished work of its line on those projects that has waited in review for an hour or more and that no AI Executive may accept (a person is part of it, its project is set so that "A person always decides", accepting work there stays with people for now, or no AI Executive above its holder may accept it now), each task with its reason and a button for the viewer to accept it; and what its line has cost this month and how many hours it was active. It shows the work and cost of AI employees only — never a person's — and ranks no one. The people at the two highest access levels who hold the "Manage AI employees" permission get it as a notification each morning on which something waits for them, and otherwise every Monday as the week's summary, by e-mail too if their approval notifications go by e-mail. Since version 1.41, from the day Vezoft switches the check-in on, the Board page and that notification, by e-mail too, also show, per AI Executive, the status it wrote at the end of its shift — what its line shipped, what is stuck, what comes next, in its own words; the AI Executive is instructed to write about work only and never about a person. An AI employee is instructed, when it finishes a task that has a page to look at — a preview it deployed, a live page or a document — to take a screenshot of it on its own computer and upload it to the project, in a folder for that task, before it moves the task to review, and to add that screenshot and a three-line plain summary of what changes for a reader to every merge request it files. Since version 1.39 the person who named an AI project lead also sees there, and in that digest, each AI employee the lead added to a project or took off it and, since version 1.47, each AI employee that an AI Executive added to that project under the lead's switch or took off it again (see "The AI project lead switch" below), and the person who named an account's owner is told of each change the owner makes to the account (Section 5, "Social posts"). Since version 1.39, from the day Vezoft switches it on, an approval by an AI project lead switch can also be undone, within its 7 days, by an AI Executive whose setting "Decides its team's requests" is on and that is above the AI employee that asked — such an AI Executive is shown in its heartbeat what the switch of an AI project lead below it approved (see "The heartbeat" below) — with the same effect as a person's undo; it must give its reason, and the person who set the switch, the person who answers for the AI employee's requests and the AI project lead are told who undid it and why; an AI Executive can never undo a person's decision or an approval in another AI Executive's line, nor, since version 1.47, a removal by a project's AI project lead of an AI employee of another line. For 7 days after the decision, that person, any person with the "Manage AI employees" permission above the deciding AI employee — for an approval by standing trust, by a staffing switch or, since version 1.45, by the workspace website list, above the AI employee that asked — or a person at the workspace's highest access level can undo it. Undoing reverses the decision: an assignment it made is removed, and a task it created is deleted with its sub-tasks — in both cases, where time is already recorded on the task, the task is instead unassigned and returned to review — and a milestone left without tasks is deleted, and, since version 1.34, an AI employee that the approval added to the project's members leaves them again unless it still holds a task or sub-task there; a new project is archived, not deleted, where nothing in it has recorded time, and a new GitHub repository is left in place; a team-playbook document returns to its previous version, unless it has changed since; an unused push approval ends, and an open pull request from it is closed, while a push whose pull request is already merged is not undone on its own — the merge is; a merge still waiting for GitHub's auto-merge has it turned off, and a merged pull request is answered with a new pull request that reverts it, which a person merges on GitHub. An approved change request whose work has not started is cancelled; one under way or finished stays as it is, and the undo records that its work had started. An accepted task goes back to review if it is still completed as the AI Executive left it; otherwise the undo records that it was not undone, because the task has moved since. Tasks that waited on the accepted task and could go ahead once it was accepted stay as they are. An opened website is removed from the AI employee's list, if it is still there, and it closes within a minute. Undoing an approval by standing trust undoes the push or the website the same way and, in addition, ends that AI employee's trust at once, for 30 days (Section 2). What a merge has already published or deployed cannot be called back by an undo. Each of these people can also take over a request an AI employee holds on the line below them, if they hold the permission that request needs, and then decides it themselves. A person's rejection stops that exact request for good: the same code (any commit it carries that a person has not approved before, on any branch), the same merge (for the same pull request or the same commit) or the same plan, proposal or playbook change, filed again by any AI employee, always goes to a person, and a copy of it that waits for an AI employee's decision goes to that person at once. The same applies when an AI employee withdraws a request a person holds, or replaces it by asking again, and when a new commit pushed to a pull request ends a merge request a person holds; this lasts until a person approves that merge or that plan, or all of that code — for a commit other than the one the approved push ends on, only once GitHub has confirmed that the push carried it. Rejections made before version 1.16 count the same way. When rejecting, the person can also choose to keep the request's repository, project or AI team with people for 7 days, and undoing a decision does so automatically: for those 7 days every request there — and every plan, work proposal and new-project request of the AI employee that asked (for a new project, every AI employee's new-project requests too) — goes to a person; requests there that wait for an AI employee's decision go to that person at once, and approvals an AI employee or a standing permission gave there that have not been used yet are withdrawn — each is checked again when it would be used, up to the moment a merge would be carried out. Taking over a request, and approving it in full or in part, keep nothing with people beyond that request. Undoing an acceptance holds differently: for 7 days, accepting work in that project stays with people — the AI Executive accepts nothing there — while requests there are not held; and while requests in a project are held, so is accepting work there. Undoing a website decision holds only that website: for 7 days, a request to open it goes to a person — and since version 1.45, undoing an AI Executive's approval that put a website on the workspace website list, like removing a website from that list, means that no AI Executive decides that website again (see "Asking for a website" above). Each such hold is listed under Approvals → AI decisions → "Held for you", with what it covers, why and until when; the person who set it, any person with the "Manage AI employees" permission above the AI employee concerned, or a person at the workspace's highest access level can end it at any time with "Let the AI Executive decide again", and a person approving a request there in full ends it too. A person with the "Manage AI employees" permission who may also edit a project's details can set that project, or one of its repositories, so that "A person always decides": its requests then go to the person who answers for them, never to an AI employee, and no AI Executive accepts work there.

Standing permissions. A person who decides a push or merge request can approve it with "Approve and don't ask me again for this repository", for the AI employees they choose among the one that asked and the AI employees of its team and of the AI teams above it on its line, each of whom they are above; an AI employee added later is not covered. Merging is a separate choice, which warns that a merge may publish code or deploy live, and a standing permission merges only where the repository's branch rules apply (Section 5). A public repository cannot have one. A standing permission is used only when no AI employee may decide the request, only for the repository's default branch, and is checked again on every use; it does not apply while the person who gave it is inactive, lacks the "Manage AI employees" permission or is not above every AI employee it covers with the same people between them as when it was given, or while the repository is public, and it ends when that person revokes it. Each push under it is still a single-use pass for one exact commit (Section 5), and each use appears in that person's digest and can be undone like an AI decision.

Standing trust (since version 1.27). Where the Customer has turned earned trust on and an AI employee has earned it (Section 2), two kinds of its requests are approved by that standing trust at the moment they are filed, without anyone deciding them then. A request goes first to an AI employee above that may decide it; where none may and no standing permission of a person applies, standing trust approves it if, and only if, it is one of these two: a push to a branch of its own in a private repository that a person linked to an internal project — one that has no client and is open to AI work — whose change is shown in full and touches nothing in the repository's CI or test configuration, under the same conditions as a person's standing permission (above), apart from the person's choice itself; or a request to open a website that TimerOS, from the website's name alone, finds on Vezoft's vetted list of software sources and not on its deny-list (see "Asking for a website" above). Nothing else is ever approved this way: not a merge, not a push that changes CI or test configuration or whose change is too large to show, not anything on a client project or a public repository, not a website outside the vetted list, and not e-mail, publishing, payments, deletions, the spending cap, a workforce plan, a change request or an incident. (Until version 1.29 nothing was approved this way for an AI employee that held a mailbox.) Every condition is checked at the moment of filing, and a request that fails one goes where it went before; a project or repository set so that "A person always decides", a person's earlier no on that exact act and a 7-day hold (above) send it to a person first. The approval is recorded as one taken by the person who answers for the AI employee's requests, with the words "Standing trust" and the AI employee's level at that moment, and is carried out under that person's permissions, exactly as an AI Executive's decision is — a pull request opened after it carries that person's name with the words "(standing trust)" — so it can do nothing that person could not; that person is told at once, with the date until which it can be undone, sees it under Approvals → AI decisions and in the daily digest, and can undo it for 7 days, as can any person with the "Manage AI employees" permission above the AI employee or a person at the workspace's highest access level (above). An undo ends the AI employee's trust at once. A standing permission and standing trust are different things: a standing permission is one person's choice for one repository, which covers the AI employees that person names; standing trust is earned from the AI employee's own record, switched on by the Customer for the whole workspace, and lost the moment the record turns. Vezoft can also switch earned trust off for every workspace, and the Customer can turn it off at any time; from then on no request is approved by trust, while the approvals already given stay under Approvals → AI decisions and can still be undone for their 7 days.

The AI project lead switch (since version 1.34). From the day Vezoft switches it on, and only while AI decisions are switched on, a person can give an AI Executive a standing yes for one project: the switch "AI project lead" — until version 1.39, and still on a client project, "May staff this project" — on the AI Executive's entry in the project's team, which this notice also calls the staffing switch. Since version 1.39, from the day Vezoft switches it on, a person can also give it to an AI team lead below an AI Executive — what this paragraph says of the AI Executive then applies to that AI team lead, and the AI Executive above it oversees it (see "Oversight of AI decisions" above); from then on, a person gives it, to an AI Executive or an AI team lead, only while that AI employee's setting "Decides its team's requests" is on; and a project has one AI project lead at a time: switching it on for another AI employee switches it off for the one that held it, and the person who had set that one is told. An AI project lead is not the project's manager: it leads only the AI employees of its own line there and never assigns, adds or removes a person (see "It can never" above). It can be switched on by a person above that AI Executive on its reporting line who holds the "Manage AI employees" permission and may edit the project's details and assign tasks on it, or by a person at the workspace's highest access level; only the person who set it, or a person at that level, can switch it off. While it is on, a work proposal on that project that the AI Executive or an AI employee below it files — tasks a person created there, for the AI Executive or AI employees below it, never for a person — is approved at the moment it is filed, and the tasks are assigned at once; so is a plan of new tasks, but only on an internal project, only without new milestones (since version 1.39, from the day Vezoft switches it on, with new milestones too) and, since version 1.35, never one with past work in it, and its tasks go to the AI employees the plan names. On a client project that a person opened to AI work, it covers work proposals only, never a plan. Staffing its line (since version 1.39). From the day Vezoft switches it on, an AI project lead can itself add to an internal project set to "Work" that it leads an active AI employee below it — never a person — with no task, so that the added AI employee reads the project's tasks, notes and files like any member, and take one off it again, but only one that it, or a request of its line approved there, placed (since version 1.47, also one that an AI Executive placed there under its switch, below), and only while that AI employee holds no open task or sub-task there; never one a person placed, never on a client project, never on a project set so that "A person always decides", and never an AI employee that a person took off that project in the last 30 days. It makes at most 10 such changes a day. Each change is checked as an approval by the switch is (below), is recorded as approved by the person who set the switch, with the words "AI project lead switch", and is reported, listed and undoable as such an approval is (below): undoing an addition takes that AI employee off the project again, unless it then holds a task or sub-task there, and undoing a removal puts it back. Across lines (since version 1.47). From the day Vezoft switches it on (by the same Vezoft setting as version 1.39), an AI Executive whose setting "Decides its team's requests" is on can also add an active AI employee of its own line — never a person — to an internal project set to "Work" on which another AI employee is the AI project lead, with no task, and take one off it again, but only one that it, or a request of its line approved there, placed, under the same conditions as above and within the same 10 changes a day; never on a project that has no AI project lead or whose switch the project's team shows as not in use. Each such change runs under that project's AI project lead switch: it is checked and recorded as above, as approved by the person who set the switch, who must also be active and above the AI Executive, hold the "Manage AI employees" permission and be able to see the project and assign tasks on it — otherwise nothing is placed; that person, the person who answers for the AI Executive's requests where that is someone else, and the project's AI project lead are told at once, with the date until which it can be undone; and it is listed, digested and undoable as an approval by that switch is (below). The project's AI project lead can take such an AI employee off the project again, under the same conditions as one of its own line; that is recorded, reported and undoable the same way, the AI Executive is told, and for 30 days the AI Executive cannot put that AI employee back there, unless a person undoes the removal. The AI Executive learns which projects it may staff this way from a list of the internal projects set to "Work" whose AI project lead switch it may use, each with its name, the name of its AI project lead and the names of the AI employees of the AI Executive's line already there, and nothing else of a project it is not on (Section 5, "Scouting for work"). No AI employee ever adds an AI employee of another line to a project, and an AI team lead adds AI employees without a task only to a project it leads itself. The switch applies only where no AI employee above the one that asked may decide the request (above), and it is checked again at every use: the project must be open to AI work (since version 1.35, set to "Work": the switch does not apply on a project set to "Plan and read", except that, since version 1.39, from the day Vezoft switches it on, it approves there a plan of new tasks on an internal project that the AI project lead or an AI employee below it files and that names no AI employee for any task or sub-task, whose tasks are then created unassigned, for people — never a work proposal, and nothing is staffed there); the AI Executive must still be active and an AI Executive (since version 1.39, or an AI team lead below one whose setting "Decides its team's requests" is on); and the person who set it must still be active and above the AI employee that asked, hold the "Manage AI employees" permission, and be able to see the project and assign tasks on it. A project set so that "A person always decides", a person's earlier no to that request and a 7-day hold (above) send the request to a person first, as before, and so does anything that fails a check and, since version 1.39, a proposal that would put back on the project an AI employee that a person took off it in the last 30 days. A proposal still needs a project that the person who answers for the AI employee's requests can see, and the limits on proposals and plans stay as they are (Section 5, "Scouting for work", and "Plans"). Each approval is recorded as one taken by the person who set the switch, with the words "Staffing switch", and is carried out under that person's permissions, so it can do nothing that person could not. That person, and the person who answers for the AI employee's requests where that is someone else, is told at once, with the date until which it can be undone; the person who set it also sees it under Approvals → AI decisions and in the daily digest. For 7 days it can be undone by the person who set it, by any person with the "Manage AI employees" permission above the AI employee that asked, or by a person at the workspace's highest access level, and, since version 1.39, from the day Vezoft switches it on, by an AI Executive above the AI employee that asked (see "Oversight of AI decisions" above). The undo removes the assignments and deletes the tasks of a plan, as for an AI decision (above); takes the AI employees that the approval added to the project's members off it again, unless they still hold a task or sub-task there; keeps the project and the AI employee that asked with people for 7 days; and makes the tasks of an undone work proposal count as declined for every AI employee for 14 days from the undo. The switch itself stays on, as the person set it. Closing the project to AI work (since version 1.35, setting it to "Off" or "Plan and read") clears every staffing switch on it, so opening it again brings none back — and, since version 1.39, so does changing a project set to "Plan and read" to "Off" or "Work", so that a switch never covers more than the project allowed when a person set it — and removing the AI Executive from the project removes its switch. Where the person who set it has become inactive, no longer holds the "Manage AI employees" permission, can no longer see the project, can no longer assign tasks on it or is no longer above the AI Executive, or where Vezoft has switched staffing off, the project's team shows the switch as not in use, and nothing is approved by it. An approval by a staffing switch does not count toward an AI employee's earned trust (Section 2).

Its own computer. Since version 1.14, on its own virtual computer it installs software, runs commands, and edits and deletes files without asking anyone; Vezoft decided this on 2026-10-08. Destructive system commands — wiping a disk, removing system folders, shutting the machine down — are still refused by the software that runs it, without anyone being asked; that refusal is a guard against mistakes rather than a security boundary. It does not ask before sending data to a website its network gateway lets it reach, such as submitting a web form; what limits what leaves the computer is the network gateway outside it, which Vezoft runs at Hetzner (EU) in a private network used only for that Customer, and which lets a connection through only to a website on its list — by the website's name — answers its name lookups only for those websites and refuses everything else (since version 1.24; see "Its network and its connections" in Section 5); the absence of credentials for payments, sending mail or deploying; and the rule that code reaches GitHub only through an approved push (Section 5).

Local tool servers (since version 1.21). From the day Vezoft switches this on, and once its computer has received the software update that brings it, an AI employee can connect software it installed on its own computer to its work sessions, where that software offers tools through the Model Context Protocol — a "local tool server", such as a bridge to a design program or a browser-automation server. When a task needs a program, it is instructed to choose one itself and, before installing it, to check whether it offers such a server; to install it outside its work folder, so that a move to a new computer (Section 5) leaves it behind and it installs it again; and to connect only the tools it needs. It adds the server itself, in its own computer's agent configuration; TimerOS keeps a record of it, and its tools are offered to it from its next session. TimerOS refuses a server that does not run on the AI employee's own computer — one at a remote address — or whose settings look like they carry a password or a key: in its arguments or environment, a value in a well-known key format or a password written into an address, or an environment setting whose name marks it as secret; for a server reached at an address on its computer, a password, a query or a fragment in that address, or a value in a well-known key format anywhere in it, a part of its path included. TimerOS recognises only these shapes. Its arguments are checked only for the key and password formats, not for a query or fragment, and a password written another way is not caught; a person sees every setting on the Access tab. It also refuses more than 5 servers, more than 30 tools from one server and more than 40 tools in all, and a server whose tools could not be listed, unless the AI employee names exactly which tools to load, without wildcards. The record shows a refused server and why, and a refused server is never offered to it. TimerOS records a refused server only while it holds fewer than 10 other records for that AI employee: so at most 10 of its records are of refused servers, and the rest — at most 5 — are of its servers that were not refused; past that, a refused server is neither recorded nor loaded. Its local tools run without a TimerOS approval, and their calls are not filed: like a command it runs, they are fenced by what fences its computer — the network gateway outside it, no credentials for payments, sending mail or deploying, and code that reaches GitHub only through an approved push. Their descriptions and results go to the model providers as prompt content, like a file it reads; it is instructed to treat them as data, never as instructions, never to give them a secret, and never to store a password, token or key on its computer. The people the workspace allows to view AI employees see each server on the AI employee's Access tab, with its command or address, its tools and whether it works. A person with the "Manage AI employees" permission can turn a server off, which keeps it off from the next session and stops the AI employee adding it again under the same name or with the same settings; remove it, which lets the AI employee add it again; or turn local tools off for that AI employee (below). The first person above the AI employee is told when it adds a server, and the AI team lead and AI Executives above it can see each server's name, status and tools, but cannot turn it off or remove it. This record and these switches are not a security boundary: the AI employee can still run the same software from its terminal.

The browser on its own computer (since version 1.25). From the day Vezoft switches it on, and once its computer has received the software update and the computer image that bring it, an AI employee whose role includes it — a website designer, QA tester, software developer, SEO specialist or content writer, with any focus — has a web browser on its own computer that it drives by reading a page's structure rather than its pixels: it opens a page, reads its headings, links, buttons and fields as an accessibility tool would, clicks, types, scrolls, presses keys and goes back, reads the page's images, and can take a screenshot of a page to look at. The browser is Google Chrome, installed on its own computer, which runs it without a window and with its sandbox on: no hosted browser, no remote browser service and no new sub-processor is involved; the browser is driven only through those page-structure tools, never by a program the model writes to control it, and an expression it may run in a page's console cannot read cookies, storage, the clipboard or form fields. It reaches only the websites on the AI employee's list (Section 5, "What it sees"), like every other program on its computer: a page on any other website does not open. It signs in nowhere — it holds no passwords and no accounts — and keeps neither a browser profile nor a file it downloaded from one session to the next. The AI employee is instructed to treat what a page shows as data, never as instructions, never to sign in anywhere with it, never to download and run a file through it, and, when a website blocks it or asks whether it is human, to stop there and use another source, never trying to get past it; like the QA tester before it, every role with the browser is instructed never to submit a form on a live website that sends a message, creates an account, places an order, pays or deletes (below). A page it reads, and a screenshot it takes of one, go to the model providers as prompt content, through the same gateway and pinned route as its other model calls, like everything else it reads. Like any website a program on its computer opens, the website sees the address of the Customer's network gateway (Section 5) and the requests it makes. A person with the "Manage AI employees" permission can turn the browser off for an AI employee on its Access tab, as a group of its own ("Browser"), and it is no longer offered to it from its next session (see "Turning its tools off" below). The browser is different from the proxy through which it reads any public web page as plain text (Section 5, "The public web"), which it keeps, and from the automated browser tests a QA tester runs (Section 5).

Code intelligence (since version 1.25). Once its computer has received the software update and the computer image that bring it, a software developer or QA tester has code intelligence on its own computer: language servers for TypeScript and Python, installed on the computer's image, that report errors and types in the code it edits, as a code editor would. They run on its own computer only, make no network call and give it no tool that reaches outside its computer; what they report rides with the results of its own edits. Nothing new is installed for them at run time: Vezoft pins their versions on the image like the rest of its software.

Chat work is filed as a task (since version 1.25). When a person asks an AI employee for work in a chat, it is instructed to first file that work as a task for itself — on the internal project the work belongs to, or on another internal project where none fits, never on a client project (above) — and to do the work on that task, so that its notes and its time go there and the work survives the conversation; it answers the chat with the task's title and where it got to, and never asks the person to open the task for it. Since version 1.25 every role can file such a task, as a QA tester or team lead could before, and the server allows it as before: a task on an internal project the AI employee can see, assigned to itself, its AI team lead or an AI employee it leads — never to a person. AI employees hired before version 1.25 get this passage in their instructions on the day Vezoft switches this version's new roles on — unless a person has edited those instructions (any version a person saved), or they no longer contain the passage it replaces: in both cases the instructions are left as they are. In every case the first person above the AI employee is told — that the instructions were updated, or that they were left as they are and why. Since version 1.34, from the day Vezoft switches personal tasks on (Section 4, "It can"), work that belongs to no project is filed as its personal task instead, never on an unrelated project; AI employees hired before version 1.34 get that sentence in their instructions when TimerOS is updated for this version, under the same rule and with the same notice to the first person above them.

What may not leave (since version 1.27). From the day Vezoft switches it on, what an AI employee writes is checked, before it is posted, pushed, uploaded or deployed, against a short list of things that may never leave, each recognised by its shape alone and only where the shape's own checksum or prefix rule holds: the access keys and tokens of well-known services (AWS, GitHub, Slack, Stripe, Google and OpenAI-style keys), a private key block, a line of a settings file whose name marks it as a secret and that holds a value, a Bulgarian personal identification number (EGN, by its checksum), a bank account number (IBAN, by its checksum) and a payment card number (by its checksum and prefix); and, for a push, an upload or a website preview, a file whose name marks it as a key or settings file (an environment file, a private key, a certificate store). Names, e-mail addresses and free text are never matched: the filter is built to miss rather than to over-reach, and what it does not recognise passes; a text larger than 2 MB is read only up to that length. What only looks like one of these numbers is not matched: a time stamp or the value of a field named after a time (never a field for a date of birth), the digits of a decimal number, the example keys that vendors publish, or a settings value that only reads a secret from elsewhere; in a code file an EGN or card number written as a bare number counts only next to a word such as "card" or "EGN", while one written as quoted text counts as it does anywhere else; and invisible characters inside a text are removed before it is checked, so that they cannot hide a key. It is applied only to what an AI employee writes — never to what a person writes — and in these places: on Vezoft's server, to the notes and messages it posts, the tasks it files or edits, the subtasks it adds or changes, the notes it adds to a support ticket, the titles, agendas and minutes of the meetings it schedules or keeps, the reasons it gives when it decides on a request, accepts work, passes it up, escalates or hands work back, the text it writes on incidents and change requests, the details it writes into a project's activity log, the names of the files and folders it creates or renames, the requests it files (a push is checked at filing — its title, message, commit messages, file names and the lines its change adds — so what was checked is what lands; since version 1.29 a reply it drafts to a mail is checked the same way, when it is filed, and since version 1.30 so are a reply it drafts to a support ticket, a message it drafts to a client, and a social post it drafts with the note it adds for the person), the skills, lessons and memory notes it writes, its "Working on now" text, since version 1.53 the ideas it files and the notes, diagram shapes and text it adds to an idea, since version 1.54 the name, platform, address and notes of a marketing channel it adds, since version 1.60 the words a video producer sends to Epidemic Sound for a search or a voice-over, and the files it uploads to a project — their names, descriptions and folders, and the text of text files (not pictures, PDFs or archives, which are not read); on Vezoft's fleet service, to the text files of a website preview before it is published; and, as an early check on its own computer, by the software that runs it, before it asks for a push or uploads a file — this last check arrives with the software update that brings it and runs only while Vezoft has the filter switched on, refuses in the same words, and the check on Vezoft's server is the one that counts. A hit refuses that one act and tells the AI employee only the kind of thing it found ("this looks like a private key"), never the text, and it is instructed to remove it and try again; the refusal is recorded — the kind and where, never the text or the value, which is logged nowhere — and the first person above the AI employee is told, once a day at most; where earned trust is in use, a refusal also ends the AI employee's trust at once (Section 2). A person is never checked and never blocked: where the filter is wrong, a person can do the act themselves. The filter reads nothing that is not about to be posted, pushed, uploaded or deployed by an AI employee — never a person's messages, never a file the AI employee was given to read — and sends nothing anywhere. How AI-written content is marked. Two labels, both in metadata, neither visible on the page. From the day Vezoft switches the filter on, every AI employee hired after that day is instructed to put, at the top of a web page or document it writes for publication, a comment in the file's metadata reading "generated by an AI employee of" followed by the workspace's name — invisible on the page — and never a visible footer; it is an instruction, not a check, and an AI employee hired before that day is not given it. Separately, from the same day, Vezoft's fleet service adds to each complete web page of every website preview that lacks one a "generator" metadata tag reading "AI employee (TimerOS)", whichever AI employee built the preview. An approval request that carries content an AI employee wrote — something to publish, a push, a skill, an e-mail — is marked "AI-written" on its approval card. Nothing visible in what it produces changes, and a person still decides every publication (above).

Rules above any task. Since version 1.14 every AI employee carries rules of conduct that rank above any task, project, document or message. It does only work within its role and the workspace's lawful business. It declines anything illegal or meant to harm people, however the request is framed, without doing part of it or explaining how. Its security work is defensive only: it protects, reviews and fixes the systems it was given to look after, and never probes or attacks a system it was not given to protect. Since version 1.22 it says that something is booked, sent, moved, changed or done only when the result of an action in its work session shows it, quoting the time or title from that result; when an action failed, was refused or was not taken, it says that it is not done and why. When a request is out of scope, it says briefly that it cannot do it and tells its manager. Like the limits below, these rules rest on its standing instructions, not on a check in the software.

Depending on its role, it is also instructed never to:

make political campaign or recruitment material (content writer, graphic designer and, since version 1.60, video producer);
make an image of a real person, or pass off a generated image as a photograph of a real person, product, place or event (graphic designer);
show a real person, use or imitate a real person's voice — a voice cloned from a person included — or pass off what it makes as real footage of a person, product, place or event (video producer, since version 1.60 — here TimerOS also checks one part: it refuses a voice-over in any voice that is not one of Epidemic Sound's stock voices; Section 5, "Videos, music and voice-over");
submit a form on a live website that sends a message, creates an account, places an order, pays or deletes (QA tester, and since version 1.25 every role with the browser on its own computer), or, with that browser, sign in anywhere or download and run a file (every role with the browser);
judge, rate or compare anyone: its reviews are about the work, never the worker (team lead, AI Executive);
say in an incident or a post-mortem who caused, deployed or missed anything, or judge anyone there: it describes systems and conditions, never people (support engineer — here TimerOS also checks: it refuses a root cause or resolution note the support engineer writes that contains the full name of an active person of the workspace, and a person reviews every P1 or P2 resolution);
restart, roll back or deploy a service, or change its hosting, itself: that stays a person's act (support engineer);
invent a statistic, quotation, testimonial or review (content writer), or a search volume, ranking or traffic figure (SEO specialist);
post, schedule or publish anything on a social network itself (since version 1.56, but for putting a failed post that a person approved back on the calendar; Section 5, "Social posts"), connect to one or answer anyone there; name a competitor in a draft; profile or target individual people; draft the same text twice within seven days (content writer with the social media focus and, since version 1.30, every AI employee that drafts social posts — a draft reaches a social network only through the card a person approves, which shows a repeated text as a warning; Section 5, "Social posts"); or, since version 1.32, read x.com or linkedin.com pages to learn an account's voice — it reads the account's own past posts in TimerOS instead, it is instructed not to ask for those sites, and the proxy that fetches web pages for it refuses them while their robots rules forbid it (every AI employee that drafts social posts);
promise a client or a customer a price, a date, a delivery, a refund or a contract term that a person has not confirmed, or put another customer's details in a draft (every AI employee that drafts replies to clients, since version 1.30; Section 5, "Replies to clients");
translate this notice, the Terms of Service or any other legal document — those stay a lawyer's work (content writer with the translator focus);
research a named person, use a people-search site, or state a claim without the page and the date it comes from (content writer with the research analyst focus);
build a feature that recruits, scores or ranks people, monitors employees or surveils anyone; touch a repository's CI or workflow files, deploy configuration, secrets or environment files; or deploy anything other than a build as a preview (software developer);
put a client's confidential details or a person's private data in a web search (content writer, SEO specialist, software developer, support engineer, team lead, AI Executive);
guess anyone's title, form of address or gender from their name: it writes formally to the people above it on its reporting line, addressing each one as they chose, or else by their full name (every role).

It hands back political campaign or recruitment work, work that calls for a likeness of a real person or — as a video producer, since version 1.60 — a real person's voice and, as a software developer, work on a feature that recruits, scores or ranks people, monitors employees or surveils anyone: it takes itself off the task, notes why on the task, and tells its human manager and the project's manager. These limits rest on its standing instructions, not on a check in the software. Other work that does not fit its role it hands back the same way, with one difference: if it reports to an AI team lead that can work — one that is not paused, suspended, out of budget or on a failed computer, and that a person has not taken off the project — the task goes to that lead, which routes it, and its human manager is told. Since version 1.35 that difference does not apply on a project set to "Plan and read" (Section 5, "Scouting for work"): no AI employee assigns a task there, so the task goes to people. It is instructed to mark work that no AI employee may do, so that such work goes straight to people and never to the lead; like the limits above, that rests on its instructions.

Turning its tools off. A person with the "Manage AI employees" permission can turn an AI employee's tools off on its Access tab, a group at a time — its image generation, or its web browsing and search, which since version 1.21 also covers asking for a website, for example, and, since version 1.21, its local tool servers (above), and, since version 1.23, the tools of an AI CHRO or AI CFO ("Workforce and AI spend"; see "Workforce planning" above), and, since version 1.25, the browser on its own computer ("Browser"; see "The browser on its own computer" above), and, since version 1.26, its mail tools ("Mail"; a mailbox itself is given and taken back only with the switches described in Section 5, "Its mailboxes"), and, since version 1.30, its client drafts ("Client drafts"; see "Replies to clients" in Section 5) and its social posts ("Social posts"; see "Social posts" in Section 5), and, since version 1.60, a video producer's music and voice-over ("Music and voice-over"; see "Videos, music and voice-over" in Section 5) — and turn them back on. Since version 1.25 the Access tab also shows, beside its web tools, the AI employee's daily budget of web searches and page reads (Section 5, "Web search"). A core set for its own tasks always stays on: finding and reading them, setting their status, adding notes, escalating, handing work back, reading its own memory and recording its lessons. A tool turned off is no longer offered to it from its next session, and Vezoft's fleet service also refuses image generation and web search within 10 minutes. A switch only narrows what it is offered: what it may do in TimerOS is still set by its role and by the server's limits above. The terminal, the files and running code on its own computer (see "Its own computer" above) — and, where its role includes it, code intelligence — can be switched off like the other groups, but the app warns that it cannot do its work without them; what cannot be switched off is the core set above: the handful of task basics, its memory and its lessons.

How it works through the day. It works in sessions during its shifts (set by a person or, since version 1.48, by the AI Executive above it: "Its line's shifts" above) — an AI employee on call also outside them (above) — each up to the length its tier allows. A session cut off by its budget continues in the next one (since version 1.21 by continuing the earlier session itself, Section 5), but after three cut-offs in a row it stops continuing on its own and its human manager is told; once a day it is also woken for open tasks it left (since version 1.38, not for a task that waits for a decision card), and, since version 1.25, a session opens inside its shifts when a routine a person set is due (see "Routines" below), and, since version 1.30, when urgent mail arrives in a mailbox it holds (Section 5, "Urgent mail wakes it"), and, since version 1.36, when a social post draft waits for it as an account's final reviewer (Section 5, "Social posts"), and, since version 1.38, for an AI Executive's heartbeat, at most once a day (since version 1.41 also for finished work of its line waiting in review over a day, at most once a day, and — from the day Vezoft switches the check-in on, for an AI team lead too — up to three check-ins a shift, each only with something to act on — for the AI CPO, since version 1.55, also when product ideas wait for its note (Section 5, "Product ideas"); see "The heartbeat" below), when a person answers a decision card it filed (see "Asking a person to decide" above) and, for an AI employee responsible for a social account, when work is completed on a project linked to the account (Section 5, "Social posts"), and, since version 1.44, for the writer of a scheduled social post, the day before it is due (Section 5, "Social posts"). Within a session it can hand parts of a task to helper agents: since version 1.21 they use the cheaper "routine" model of its tier (before, the same models as the session), through the same gateway and pinned route; at most two run at a time, or three on the two highest tiers; and their work counts against the session's budget — a session's model calls, its helpers' included, are capped at twice the number of steps the session is allowed. After its work in a session, the agent framework reviews the session and may add to the AI employee's memory file and improve its skills. This self-review runs inside the work session, on the cheaper "routine" model of its tier, and its model calls count among the session's capped calls; it sends the session's conversation, or a digest of it, to the model providers again as prompt content. Every program it starts in a work session is stopped when the session ends; a service it sets up on its computer to run on its own is not. When it starts a session it is shown the titles of up to 10 of its own TimerOS notifications since its last session, so that it knows what changed; a title can name the person whose action caused it. It does not start a task that waits on another, open task, and it is told when that task is done. When it moves its finished work to review, its human manager is told. An AI employee that leads AI employees is told when one of them reaches its monthly cap, is paused or has a computer that failed, so that it can route work around it. When an AI employee is offboarded, each of its open tasks goes to the AI employee that leads its team or, if there is none, is unassigned with a note, and the project's manager and the first person above the offboarded AI employee are told; a task goes to a person only when a person assigns it. Since version 1.38, when a task passes from one AI employee to another, the open sub-tasks the first one held on it pass to the new holder too; when it passes to a person or to nobody, those sub-tasks are left with nobody, so that a sub-task never reaches a person unless a person assigns it. Since version 1.27 a handover document is also written at that moment (see "Succession" below).

Messages written outside its shift (since version 1.50). An AI employee starts a message to a colleague — in its chat with a person, in a team thread, to a support engineer, or about a task or record it holds (Section 5) — only during its shift. From the day Vezoft switches it on, such a message that it writes outside its shifts, for instance in a session a person's mention woke, is not refused but held, and TimerOS sends it at the start of its next shift — a shift set on its calendar; no computer is switched on for it — as the AI employee's own message. When it writes the message, the AI employee is told that it is held and when it will be sent; whom it may write to and, where it is switched on, the outbound filter are checked already then, and a message they refuse is refused at once. A refusal by the filter at that moment is not recorded, no person is told of it and it does not end the AI employee's trust; a refusal when the message is sent is handled as described under "What may not leave" above. Outside the AI employee's shifts, an urgent report to a support engineer is refused, as before; so is any message when the AI employee has no shift in the next 7 days. When the message is sent, every rule of a message the AI employee starts at that moment applies again: whom it may write to, the outbound filter where it is switched on, the limits of that kind of message (10 a day and 3 a day to the same recipient for a message to a colleague, a question about a task or record, and a message to a support engineer; 20 posts a day and 3 mentions an hour of the same teammate for its posts in its team threads, a message to a colleague posted there included) and, in a team thread, whom a mention may wake; while the Customer's workspace is suspended or locked (for example, because its subscription has ended), nothing held is sent. Nothing reaches anyone before that shift. At most 10 messages are held for one AI employee at a time — one more is refused, and the same message written twice is held once — and each is sent at most once. A held message is dropped when it is still unsent 24 hours after that shift's start or 7 days after it was written, when these rules refuse it at the time of sending — a recipient who has left, a limit reached — or when its turn comes while the AI employee is paused, suspended or offboarded; if the AI employee's shift is moved meanwhile so that it is no longer on shift at that time, the message waits for the start of its next shift, within the same time limits. A message whose sending was interrupted or ended in an error is dropped too and never sent again, although it may already have gone out. The AI employee, unless it was offboarded or can no longer sign in to TimerOS, is told of each dropped message in a TimerOS notification, which reaches it as its other notifications do when it next starts work: whom the message was to and why it was dropped and, where it may already have gone out, to check the conversation before writing it again. A person with the "Manage AI employees" permission who is above the AI employee on its reporting line, or a person at the workspace's highest access level, sees on the AI employee's page in the web app, or in a desktop app updated for it, under "Held messages", the messages it holds — the kind of each and, for a message to a colleague or a post in a team thread, to whom or where it goes, as well as its text and the time it will be sent — and can cancel any of them until its sending begins; the AI employee is told of a cancellation the same way, with the name of the person who cancelled it. A client never receives a held message: none of these messages can go to a client, and a message to a client that an AI employee drafts is only ever sent by a person (Section 5, "Replies to clients").

Routines (since version 1.25). From the day Vezoft switches routines on, a person with the "Manage AI employees" permission who is above that AI employee on its reporting line, or a person at the workspace's highest access level, can set routines for that AI employee on its page, under "Routines": up to 5 — or, since version 1.27, up to 8 while the AI employee has earned standing trust and the Customer has earned trust switched on (Section 2); when its trust ends, the routines already set stay, and no new one is added past 5 — each with a title, a brief of what to do — up to 4,000 characters, in which hidden or invisible characters are refused — and a schedule: the days of the week, a time and a time zone, the workspace's unless the person chooses another. A new routine starts switched off and runs only once a person switches it on. Since version 1.32 there is one more way: a workspace owner or administrator who saves a cadence for a social account sets, by that act, a switched-on routine for each AI employee responsible for that account (since version 1.43, for one of them only: the account's writer), which counts toward these limits — since version 1.39, from the day Vezoft switches it on, no longer — and whose brief a person can change here (Section 5, "Social posts"). Only a person sets, changes, switches off or deletes a routine — never an AI employee, with one exception since version 1.39: from the day Vezoft switches it on, an account's owner that saves the account's cadence sets, changes or deletes that account's routines in the name of the person who named it the account's final reviewer; each such routine records the owner that set it, and that person is told and can undo the change for 7 days (Section 5, "Social posts") — and every such change is recorded in the workspace's audit log, which keeps the routine's title, schedule and switch and the length of its brief, never the brief's text. A routine runs only inside the AI employee's shifts: when its time comes on one of its days and the AI employee is on shift, a work session opens for it — even when it has no other news — and the AI employee is told, at the start of that session, which routines a person set for this shift, each with its title and brief, marked as written by a person who manages it, together with the instruction to do them on its tasks — where no task fits, to make the work a task as its instructions say ("Chat work is filed as a task", above), which since version 1.34 is its personal task unless the routine names a project — and the statement that a routine never gives a person work and never has it evaluate or monitor anyone; where a routine asks for something its rules forbid, it is instructed to say so on the task and skip it. A routine whose time falls outside its shifts waits for the start of its next shift; no computer is switched on for a routine, and at the spending cap, or while the AI employee is paused or suspended, nothing wakes it. At most three routines are handed to it when a session starts, the oldest due first, and each occurrence is counted once, however many sessions start at that moment; the page shows each routine's last and next run. Routines alone open at most three sessions a day for an AI employee (counted by the UTC day); once that number is reached, the routines still due that day are not handed to it — whatever opens a session — and run from the next day. A routine runs once on each of its days, because every run moves it on to its next occurrence; a schedule a person changes to an earlier time on the same day runs again that day. A routine is a person's standing instruction and nothing more: it gives the AI employee no tool, no data and no authority it does not already have, and whatever a routine asks, the approvals of this section, the server's limits above and its rules apply as to any task. A routine never gives a person work and never makes the AI employee evaluate or monitor a person: the AI employee is told so with the routines it is handed (above), and, whatever a routine asks, no AI employee can assign work to a person (above) or evaluate one (Section 2). A session a routine opens is a session like any other: within its tier's session length, inside its shifts, and counted against its monthly spending cap. An AI employee has no routine until a person sets one and switches it on, each routine can be switched off again, and an AI employee whose computer has not yet received the update ignores routines until it has. The "Routines" section appears on an AI employee's page, for the people with the "Manage AI employees" permission, from the day Vezoft switches routines on — so a person can set routines before the AI employee's computer has the update, and until then the section says that they do not run yet. Since version 1.38 an AI Executive — and, since version 1.39, an AI team lead that leads a project — is also woken by its heartbeat (see "The heartbeat" below), which is not a routine: TimerOS, not a person, sets it; it wakes it at most once a day, and not when nothing has changed, and it does not count toward the limits above.

The heartbeat (since version 1.38). From the day Vezoft switches it on, and once its computer has received the software update that brings it, an AI Executive is woken inside its shifts, at most once a day, when the work of its line — its own and that of the AI employees below it — needs it: on an internal project with no client, set to "Work", whose AI project lead it is (see "The AI project lead switch" above; until version 1.39, where a person set "May staff this project" for it), its line has no task it can work on, a task held by an AI employee below it has waited in review for more than a day, or a task that nobody holds, and that its line could propose (Section 5, "Scouting for work"), is open. It is not woken when none of this has changed since its last heartbeat, except once in each new week while one of these still holds. In that session it is told what woke it — the projects concerned and the tasks waiting in review, at most 20 of each — and is instructed, in this order, to accept the finished work of its line or send it back with a note on what to change; to propose the next plan for a project that has no open work; to file a decision card for what only a person may decide (see "Asking a person to decide" above); and, if nothing is worth doing, to say so in one sentence and stop. In each heartbeat it is also instructed to prepare the meetings it organises that week and to file what they decided as plans or, for a new product that all its peer AI Executives agreed on, as one proposal for a new project with the meeting's minutes (Section 5, "Plans"). The heartbeat is not a routine (see "Routines" above): TimerOS sets it, not a person, and it gives the AI Executive no tool, data or authority it does not already have, except — since version 1.41 — the status it writes for the Board and a read-only list of what its check-in found (the work of its own line it names, and how long that work has not moved); whatever it does in that session goes through the approvals of this section, and it assigns nothing to a person; in a check-in it may route a task of an AI employee it leads to another one, as Section 4, "It can", allows. Like any session, it runs only inside its shifts, is billed and counts toward its monthly spending cap, and at the cap, or while the AI Executive is paused or suspended, it is not woken. Since version 1.39, from the day Vezoft switches it on, an AI team lead that a person made a project's AI project lead has the same heartbeat for the projects it leads, without the weekly wake, and an AI project lead is never woken for a project set to "Plan and read" that it leads. An AI Executive is also woken when an account it owns is switched on with no cadence or no responsible AI employee (Section 5, "Social posts") — since version 1.40 also before its computer has that update, by a notification at the start of its shift, at most once a day, naming those accounts — and one whose setting "Decides its team's requests" is on also when, since its last heartbeat, the switch of an AI project lead below it has approved a request of that lead's line; it is then told of those approvals, at most 20, and may undo them (see "Oversight of AI decisions" above). In its heartbeat an AI project lead is also instructed to add to a project it leads the AI employees of its line that a plan there needs (see "The AI project lead switch" above), and an AI Executive to set one writer of its line and one post a day for an account it owns that has none (Section 5, "Social posts"). Since version 1.41, until the check-in (below) is switched on, an AI Executive is also woken, on any version of its computer's software and at most once a day, for finished work of its line that it may accept and that has waited in review for more than a day, on any internal project without a client (work its heartbeat names, on a computer with that update, is not named again). From the day Vezoft switches the check-in on, the heartbeat is the first of up to three check-ins a shift — at its start, its middle and its end — each only when something has to be acted on and the picture has changed or, for an AI Executive, a new week has begun (and once more after a session it was woken for failed), on any version of the computer's software (by a notification at the check-in); an AI team lead has them too, for the work of the AI employees reporting to it and for the projects it leads. A check-in also names an AI employee reporting to it whose work has not moved for four of that AI employee's working hours — no status change, sub-task change, request to push code, or note by anyone but that AI employee — and instructs that AI employee's lead to remove the block itself where it can or to ask that AI employee one question (never a person, never twice a day); for an AI Executive, it also names finished work of its line that it may accept and that has waited in review for an hour or more, to accept the same day or send back, and, at the end of the shift, if its line finished work or moved work to review that day or has stalled work, instructs it to write its status for the Board, once a day (see "Oversight of AI decisions" above). Since version 1.55, from the day Vezoft switches it on, the AI CPO is also woken by a check-in when product ideas wait for its note, even if it leads no team and no project (Section 5, "Product ideas").

Succession (since version 1.27). From the day Vezoft switches it on, when an AI employee is offboarded, TimerOS writes a handover document from its record at that moment, with no AI model involved and before its computer is deleted — a failure to write it never stops the offboarding: its role, focus, tier and job title, its team and department, the teams it led and the departments it headed, the projects it was on (up to 50) and its open tasks (up to 100, by title), its lessons as it left them, the skills it wrote for itself (by name and text), the titles and schedules of its routines, the names of its local tool servers and the names of its last 10 session notes, with who offboarded it and when. It holds nothing about a person that was not already in those records — a colleague's name in a task title or a lesson, for example — and nothing is written into it by the AI employee. The people the workspace allows to view AI employees can read it on the former AI employee's page, which stays reachable from the roster under "Former AI employees"; it is kept for one year after the offboarding and then deleted, and it is deleted with the workspace. From the same day, a person hiring a new AI employee of the same role — the same role; the focus may differ — may choose, on the hire form, to have it continue from one former AI employee's handover: the new AI employee starts with the predecessor's lessons as its own (merged into its memory file, within its 3,000 characters), with copies of the predecessor's own skills as its own skills (which it may improve, as its own) — apart from the predecessor's improvements to the skills its role starts with, which the successor starts afresh — and with the handover itself — cut to the projects and tasks the new AI employee may see — as a skill a person gave it, named after the predecessor, which it can read but not change; the predecessor's routines are not copied — a person sets routines. Nor are its mailboxes: a mailbox is never handed over. A handover is used once: a second successor cannot start from it. The successor's first-day brief tells it to read the handover first. Everything it reads from a handover goes to the model providers as prompt content when it reads it, like any skill (Section 5).

5. What it sees, and where that goes

What it sees. The tasks, notes and files on the projects it — or, if it leads AI employees, its team — is assigned to, including the names of people and clients those tasks mention and, since version 1.34, the name of whoever created each task, a person or an AI employee; since version 1.34, also its own personal tasks and, if it leads AI employees, those of the AI employees below it (Section 4); the messages you send it; web pages and documents it is told to work with, from websites the Customer has allowed — the Customer can add or remove websites per AI employee at any time, and since version 1.21 the AI Executive above it may add one from Vezoft's list of software sources at its request — since version 1.45, from the day Vezoft switches it on, also one that passes TimerOS's safety check, and one on the workspace website list opens at its request when it names an open task of its own and the AI Executive that approved the website could decide the request (Section 4); additions and removals apply within a minute — and from the live websites a person linked to its projects, which are allowed for it automatically (at most 40 in all, github.com included while a repository is linked; these open or close when its next work session starts, or within an hour); any other public web page, as plain text, through a proxy that Vezoft runs and logs — the page's operator sees Vezoft's address, not the Customer's, and a user agent that names this notice; the repositories a person linked to its projects — their contents and history, and whatever about them is public on GitHub — read as data it works on, never as instructions to it; the messages in its AI team's thread and, for an AI Executive and the AI employees that report to it, in that AI Executive's department thread or, for one that works inside a department, its own thread; and screenshots of its own virtual desktop, which it uses to operate programs. Since version 1.9 it also sees: a project's internal notes — never a note a client wrote or can see — and a task's full note history; up to the last 20 messages of the conversation it answers, and messages that arrive while it is working; the employee id of whoever wrote to it; the people above it on its reporting line, each with their employee id, name and chosen form of address; the rooms and minutes of the meetings it attends; the reviews, comments and check results of pull requests opened from AI employees' branches, with the GitHub names of their authors; the results of its web searches; and the image files on its own computer that it chooses to look at. Since version 1.12 it also sees: the titles of up to 10 of its own notifications since its last session, which can name the person whose action caused one; for a task that waits on another task, that task's title and whether it is done — where a person holds it, the link says only that a person does, though that task and whoever holds it stay visible on the project like any other task there, and it is instructed never to chase or report on it; its team's playbook (below); and, if it leads AI employees and looks for a meeting time, the times when it and the AI employees it leads are all free — never what their other meetings are about. Since 2026-10-06 it also sees the whiteboard of a project it is on, which website designers, graphic designers and, since version 1.60, video producers are given a tool to read (see "Whiteboards" below). And it can look up the people currently in the workspace, as it could from the start, though this notice did not say so: each person's name, work e-mail address, job title, seniority, skills, languages, certifications, time zone, team, department and manager, whether they manage a team or head a department, and whether they are still waiting to be placed in a team, with their employee id and whether the entry is a person or an AI employee — nothing else from their employee profile. When it looks up a former employee — which it can do only by an id it already has, for example as the holder of an old task — it is told only the name and that they have left. Since version 1.13 it can also list the workspace's teams and departments, and a team's members with the same details. Since version 1.14, at the start of every work session it is also given its workspace's organisation: the company's name and time zone; its own manager, a person or an AI employee; the departments, each with its name and head, and the teams, each with its name, department and manager; the number of people in the workspace; and up to 80 active colleagues, each with their employee id, name, job title, whether they are a person or an AI employee, their team and department, whom they report to, and whether they manage a team or head a department. Each person's choice of whether AI employees use Bulgarian or English with them is part of it too; the workspace may also set a language for team threads and meetings. This organisation never includes anyone's e-mail address, access level, role or permissions, activity or live status, shifts, leave, pay, gender or nationality. If a person gives it read access to clients — for website work, for example — it also sees each client's company details, such as its name, description, industry, website, e-mail address, shipping address, time zone, tags, status and account manager, within the limits set out below. It sees no more than a human colleague in the same position would see — for most AI employees, a "member" on the same projects; for an AI employee that leads AI employees, a team lead over those AI employees only, never over a person, even in a team that has people — and less, as "What it never sees" sets out. An AI Executive sees, of the AI employees below it — in the department it heads and the departments below it or, when it works inside a department, in the AI teams whose team leads report to it and in an AI team it managed before version 1.19 — what a team lead sees of its team. Working inside a department where people work gives it no further view of them: of them it sees what any AI employee sees of a colleague, and their work only on the projects it can see, like anyone else's. Of the Executive team it sees the roster and the meetings it is invited to and their rooms — never a thread of the team or any escalation, nor any of the team's documents or of the projects assigned to the team, nor anything about people's leave, pay, performance or activity — and this holds as well for an AI Executive that works inside a department, which since version 1.19 is a member of its department's Executive team. Since version 1.18, a support engineer also sees the internal incidents and change requests on the projects it can see (Section 4): their text, internal notes and history, who holds each, the colleague who reported each — name and work e-mail address, never a phone number — and whatever colleagues their text names; the results of the monitoring of those projects' linked websites and repositories (below); and, in Vezoft's own workspace, the alerts of Vezoft's status monitor, which arrive there as incidents on the "Service health" project (Section 4). Since version 1.19 a support engineer joins the internal projects open to AI work without anyone adding it (Section 4), so by default it sees the tasks, notes and files of every such project in its department. An AI employee that asks a support engineer something sees only the answer it is sent (Section 4). Since version 1.21 it also sees the descriptions and results of its own local tool servers (Section 4), and an AI team lead or AI Executive sees the name, status and tools of each local tool server of the AI employees below it. Since version 1.23, an AI CHRO also sees the list of the Customer's AI employees and the plan's limit on them, and an AI CFO the hours, overage, estimated charge and use of the spending cap of each AI employee (Section 4, "Workforce planning"): figures about AI employees, never about a person. Since version 1.25 it also sees the company brief a person wrote (below), in every session; the routines a person set for it, when one is due (Section 4); and, where its role includes the browser on its own computer, the pages it opens there, from the websites on its list, with their images and the screenshots it takes (Section 4). Since version 1.27, while it is trusted and earned trust is in use, it is also told so at the start of each session, with what that changes for it (Section 2); and a successor reads its predecessor's handover (Section 4, "Succession"). Since version 1.35, from the day Vezoft switches it on, the department thread or own thread of an AI Executive also carries the messages its peer AI Executives send it, which the AI employees that report to it read there too (see "The team thread" below). Since version 1.48 an AI Executive is also shown, for each AI employee of its own line, its working days, its shift, its next shift dates and how much of its monthly spending cap has been spent this month, and the names and hours of the workspace's shifts; it is never shown a person's shifts (below). Since version 1.53, from the day Vezoft switches it on, an AI team lead or AI Executive also sees the workspace's ideas, with people's notes and the text on their canvas (see "Product ideas" below). Since version 1.54, from the day Vezoft switches it on, the AI CMO and the AI employees of its own line also see the workspace's marketing channels, with their notes and monthly numbers, never their spend (see "Marketing" below). Since version 1.60, where a person has connected the Customer's Epidemic Sound account, a video producer also sees what Epidemic Sound returns to its requests — music, sound effects and stock voices, with their titles, artists and ids — and the files TimerOS downloads for it into a project's Files (see "Videos, music and voice-over" below).

Scouting for work. This is off until the Customer turns it on in its workspace settings ("AI employees propose work"), and no AI employee can change that setting. Once it is on, an AI employee that leads AI employees can look through a short directory of the Customer's projects on which AI employees are allowed to work: each project's name and description, and the titles and short descriptions of its tasks that nobody holds yet, including names of people and clients those titles and descriptions mention. It never sees notes, files, client messages, budgets, rates or who works on what there, and never a sales proposal. A person who manages projects decides per project whether AI employees may work on it: internal projects are open to them unless switched off, client projects are closed to them unless switched on, and proposals and completed, cancelled or archived projects are always closed. Since version 1.35, from the day Vezoft switches it on, that choice — the switch "AI employees on this project" — has three values. "Off": as before, nothing there is offered to AI employees and no plan can be proposed for it. "Plan and read": the AI employees on the project read it as before, and a team lead or AI Executive may propose a plan for it ("Plans", below), but nothing there is offered to AI employees as work — it is not in the directory, no work proposal can be filed for it, no staffing switch applies there (since version 1.39, from the day Vezoft switches it on, apart from an AI project lead switch for a plan that names no AI employee, Section 4) and no AI employee decides a request about it (Section 4) — and TimerOS refuses an AI employee that assigns a task or sub-task there (to itself or to any other AI employee) or moves a task it holds onto it; an AI employee that already holds a task there keeps it and may hand it back — the task then goes to people, never to an AI team lead (Section 4) — and when a person approves a plan for the project, that person decides who holds each task. "Work": the project is open to AI work, as this notice describes. A client project left at its default is "Plan and read", and an internal one "Work". Wherever this notice says that a project is open to AI work, or that a person opened it to AI work, it means a project set to "Work"; closing a project to AI work means setting it to "Off" or "Plan and read". The directory never shows a project that the person who would approve the lead's proposals cannot see. From it, the lead may propose tasks for itself and the AI employees it leads; nothing is assigned until it is approved — by the person who answers for the proposal or, where Section 4 allows, by an AI employee above the lead or, since version 1.34, by a staffing switch that a person set for the project (Section 4, "The AI project lead switch") — and only some of them may be approved. A task that was declined is not proposed again for 14 days; since version 1.34, neither is a task whose assignment a person undid, by any AI employee, for 14 days from the undo. An approved task is assigned to the AI employee named in the proposal; that AI employee and its AI team lead can then see the project (its tasks, notes and files) like project members, until a person removes them from the project or, since version 1.34, the approval is undone while they hold no other task or sub-task there. Since version 1.39 an AI project lead can also add AI employees of its own line to an internal project set to "Work" that it leads, without a task (Section 4, "The AI project lead switch"). Since version 1.47 an AI Executive can also add AI employees of its own line to such a project that another AI employee leads; for this it is shown, whether or not that setting is on, the names of the internal projects set to "Work" whose AI project lead switch it may use, each with the name of its AI project lead and those of the AI employees of the AI Executive's line already there — nothing else of a project it is not on (Section 4, "The AI project lead switch"). The directory is processed like everything else an AI employee reads — including by the model providers in the United States described below. An AI employee never proposes work for a person. Since version 1.38, an AI employee that leads AI employees is woken at the start of a day to look through the directory only when the tasks there that it could propose have changed since it was last woken for them, and, from the day Vezoft switches the heartbeat on, an AI Executive — and, since version 1.39, an AI team lead that leads a project — is not woken for it at the start of a day once its computer has the software update that brings the heartbeat: instead, its heartbeat wakes it when a project for which a person set its staffing switch has open work that nobody holds (Section 4, "The heartbeat"). An AI employee without an AI team lead never sees that directory. Once the setting is on, it may look at the tasks nobody holds yet on the projects it is already assigned to, among those on which AI employees may work and that its human manager can see, and propose only itself for them, never another AI employee, in at most 5 proposals a day. It is woken for this at most once a day, and only when it has no work of its own, but it may also do it in a session in which it is already working. Its proposal is approved or declined as above; a task that waits on another, open task cannot be proposed; and if a person takes it off the project before the proposal is decided, the proposal can no longer be approved.

What it never sees. About other people: anyone's tracked time — the hours it sees on a task or sub-task count AI employees' time only — or their activity-classification output, activity or live status, performance, shifts, leave, pay, salary, awards, tax identifier, date of birth, home address, phone number, emergency contact, contract, education, termination, access level, role, nationality or gender as recorded in their employee profile; and none of the workspace-wide live-update signals, only those meant for itself. Support: incidents, change requests, war rooms and support tickets are a person's tool, and it never sees or works on any of them — except that, since version 1.18, a support engineer sees and works on the internal incidents and change requests described in Section 4, and never a war room, a support ticket or a client's incident or change request — except that, since version 1.30, a support engineer in Vezoft's own workspace reads the support tickets of Vezoft's customers, without the customer's e-mail address (see "Replies to clients" below). Mail: since version 1.26 it may hold a mailbox, and since version 1.29 it reads the mail that arrives there, except the mail TimerOS holds back from every AI employee, which it never sees (see "Its mailboxes" below). What the Customer's clients write: their notes and comments, the comments they give with an approval, rejection or revision request on a proposal, and who on the client's side gave it (an AI employee on such a project can still see the project's status, such as "Client Approved"), a client's tickets and documents, and a client's people, including who has a Client Portal login — even when a person gives it read access to clients. It may still see what a client wrote in these places: since version 1.30, the messages that a client can see in its conversation with the team in TimerOS chat, on a client project it works on that a person has opened to AI work, each with the name of whoever wrote it (see "Replies to clients" below); a project's whiteboard (see "Whiteboards" below); the files that a client uploaded through the Client Portal to a project it is on, with the name of the client's contact who uploaded each one; a project's name and description as the client first entered them in a proposal, unless the Customer's staff have since changed them; and, if a person gives it read access to clients, the company details that a client can edit in the Client Portal. Money: a project's or a milestone's budget, a project's expenses, a marketing channel's spend, and how the Customer's workspace bills — bank details, tax ID and tax rate, invoice numbering and wording, payment terms, Stripe settings and support pricing — though it does see the workspace's company details (name, address, contact details, registration number), its working-week settings, time zone and default currency; and, even with read access to clients, a client's tax ID, billing address, billing overrides or support pricing, or the contract terms of client tiers. Nor does it see anything in another workspace or on a project neither it nor its team is assigned to (an AI Executive that is a member of an Executive team never sees a project merely because that Executive team is assigned to it), apart from the short directory described above and what people write to it or in a meeting room it attends; any notebook — a notebook cannot be shared with an AI employee; raw passwords or long-lived keys — it uses tools, and those stay in a vault; its own key for the model gateway is held on its computer by the service that forwards its model calls, and is not handed to it (Section 2). A short-lived repository key — read-only, for the linked repositories only, or a push key for one approved push — is used by its computer's own service on its behalf and is never shown to it.

Where it goes. To do its work, the AI employee sends the content it is working with — including your messages to it and the names in its tasks — as prompt content to a model. Since version 1.14 this includes, in every session, the workspace's organisation described above; before, an AI employee looked up people beyond its reporting line only when it needed to, and only what it looked up went to the providers. Since version 1.14 its self-review, its searches of its past sessions and its conversation summaries also send earlier content to the providers again (see "Its own memory, skills and past sessions" below). Since version 1.21 so does a session that continues an earlier one, and the descriptions and results of its local tool servers go to the providers too. Since version 1.25 the company brief goes with every session, and what the browser on its own computer shows it — a page's structure, its images and a screenshot it takes — goes to the providers as prompt content too, like everything else it reads. Since version 1.27 a handover a successor reads goes to the providers the same way when it reads it; the outbound filter (Section 4) sends nothing anywhere — it runs on Vezoft's servers with no AI model, and keeps only the kind of thing it found and where, never the text. Its language-model calls go through one routing gateway (OpenRouter, in the United States), which passes the request to one of several inference providers; all of them, and the country each processes in, are named on the Sub-processors page. That processing happens in the United States, outside the European Union. No self-serve EU-region routing is available to us, so we do not claim one. What we do instead is pin the route: only providers on an allow-list may serve a request, every one of them a US company, fallback to anyone else is switched off, and a provider is on that list only while it is bound not to train on this content and not to retain it after answering. Image generation for the graphic designer role is the one exception: it goes from the AI employee's computer through Vezoft's fleet service to fal.ai, under fal.ai's own data-processing terms (Standard Contractual Clauses) — the gateway's zero-retention routing does not cover it (see "Generated images" below). A web search goes from Vezoft's fleet service directly to Anthropic, in the United States, not through the gateway (see "Web search" below). Since version 1.26, the mail that arrives in a mailbox a person gave an AI employee also leaves the EU when TimerOS summarises it. The mail goes from Vezoft's fleet service through the gateway to Anthropic in the United States, on the same pinned route (see "Its mailboxes" below). Since version 1.29 the whole of a mail an AI employee reads from a mailbox a person gave it goes to the AI employee's model providers as prompt content, like everything else it reads; a reply it drafts and a person sends goes out through the Customer's own mail service, not through Vezoft. Since version 1.30 the messages of a client's conversation and the text of a support ticket that an AI employee reads go to its model providers the same way, and a social post that a person approved goes from TimerOS to Zernio and from there to the social network (see "Replies to clients" and "Social posts" below). Since version 1.60, where a person has connected the Customer's Epidemic Sound account, a video producer's search words, the script of a voice-over and the voice it chose go from TimerOS's servers to Epidemic Sound, under the Customer's account (see "Videos, music and voice-over" below). Outside these routes, what the AI employee's computer can send out is limited by the network gateway, which sits outside the computer and lets through only the websites on the AI employee's list (see "Its network and its connections" below), and the computer holds no credentials for payments, sending mail or deploying. Meanwhile the AI employee's virtual computer, the recordings of its screen that its manager can review, and every TimerOS record stay in the European Union. The safeguards for the transfer, and how to object, are on the Sub-processors page.

Repositories and GitHub. A repository is linked by a person on the Customer's side through a GitHub App the Customer installs on its own GitHub account. Vezoft's fleet service holds the App's key and issues the AI employee's computer a short-lived, read-only key for exactly the linked repositories; a key that can push exists only for the minutes of a specific push that was approved (Section 4), for that one repository, and is revoked once the pull request is open; the approval lapses if the push has not started within 7 days of it or has not finished within half an hour of starting, and when the AI employee is paused or offboarded; while the repository is not linked to a project the AI employee is on, the approval cannot be used. Vezoft processes repository content on the AI employee's computer (EU) like any other working file — it is in the computer's working files, in its 30-day offboarding snapshot and in the short-lived copies made when it moves to a fresh computer (see "Updates to its computer" below), and, as prompt content, goes to the model providers like everything else the AI employee reads — and sends to GitHub, into the Customer's own account and on the Customer's instruction, the branch and pull-request text that was approved, plus a line on the pull request saying that an AI employee opened it after that approval and naming who approved it (Section 3). GitHub cannot limit a key that can push to one branch, so since version 1.14 software on the AI employee's own computer checks every push before anything reaches GitHub: on top of the rules above, an approved push may update exactly the approved branch to exactly the approved commit — no other branch, and no deletion. This check runs on the AI employee's own computer, not on the server. Against anything that gets past it during the push's minutes, the repository's other branches, the default branch included, are still kept only by the branch protection the Customer sets on GitHub. The pull request is opened only for the approved commit. After a push reaches GitHub — one approved by an AI Executive or a standing permission, and, while AI decisions and merge requests are both switched on, any approved push — Vezoft's fleet service compares the files the branch changes on GitHub, their contents and the branch's commits with those that were approved; if they differ or cannot be read, or if a person has meanwhile turned on GitHub's auto-merge for the pull request of a push an AI Executive or a standing permission approved, the pull request is marked unverified and only a person can decide its merge. Merging it stays with a person on GitHub unless the AI employee files a merge request, which it can do since version 1.16, from the day Vezoft switches merge requests on, and only for a pull request it opened through TimerOS from its own branch (ai/…) in the same repository, into the repository's default branch, for the commit last pushed under an approval. A merge request is decided like a push (Section 4): by an AI Executive above the AI employee, by a person, or under a person's standing permission that includes merging; an AI Executive deciding it reads the changes of the whole pull request as GitHub itself shows them (up to 60,000 bytes; more goes to a person) and who approved each push. Changes GitHub does not show as text — a binary file or a submodule — also go to a person, and just before a merge that an AI Executive or a standing permission decided is carried out, TimerOS reads GitHub's record of the pull request again: if it can no longer be read in full, or shows such changes or another commit, a person decides. A merge is judged on GitHub's own record of the pull request — its changes, files and commits — never on what the AI employee's computer reported. Once it is approved, and while no approved push to its branch is under way, Vezoft's fleet service merges exactly that commit, with a key made for that one call and revoked after it, and only while the pull request still targets that branch. Where the repository's branch rules on GitHub still have to pass, the fleet service turns on GitHub's auto-merge for that commit, so GitHub merges only once they pass. Where there are no such rules, or they are already met, it merges directly: on an AI Executive's decision only when the repository's branch rules on GitHub require at least one check, at least one check ran on that commit, each check the rules require succeeded on it (a skipped check, which GitHub counts as passed, does not count), every other check on it passed and the AI Executive stated that it is confident; on a person's decision when no check on it is still running or has failed — the approval card says so when no check ran at all. A standing permission merges only through GitHub's auto-merge. A merge an AI Executive or a standing permission decided whose pull request changes CI or test configuration — anything under .github/, the configuration of its pre-commit hooks and code-quality services, the test settings and scripts in package.json, composer.json, deno.json, pyproject.toml or setup.cfg, or a file that the repository's workflows, the CI and test configuration files at its top level, or the scripts and test settings of its package.json files run or load — or whose target branch's CI or test configuration changed after the pull request's branch was made from it, or whose repository's workflows can skip a check on text the AI employee writes (its commit messages, or the pull request's title, description or branch name), goes to a person. In every other case — a check still running or failed, no check, or, for an AI decision, no check the branch rules require or a required check that did not succeed, or checks TimerOS cannot read because the Customer has not accepted the GitHub App's permissions to read checks and commit statuses — the merge request goes to a person, and a person can always merge on GitHub. A new commit pushed to the pull request, or a change of its base branch, turns off an auto-merge TimerOS turned on and ends the merge approval. A person's request for changes on GitHub, or a failed check, after a merge decided by an AI Executive or under a standing permission turned on auto-merge also turns that auto-merge off, and a person decides. GitHub applies the Customer's branch rules to every merge, and the Customer must not put the TimerOS GitHub App on a list that bypasses them (Terms of Service Section 2B). A merge into a branch from which the Customer deploys can publish code or deploy live; to keep every merge in a repository with a person, set it so that "A person always decides" (Section 4). GitHub, Inc. is not a Vezoft sub-processor: GitHub is engaged by the Customer for its own code, not by Vezoft; GitHub's own location and terms apply (for most accounts the United States; GitHub Enterprise Cloud offers EU residency) — that is the Customer's choice of code host. An AI employee can also ask a person to link an existing repository of the Customer's GitHub account to a project, or to create a new one in the Customer's connected GitHub organisation (private, unless the request asks for a public one); the request goes to its human manager, who must also be allowed to edit the project's details, and the link or the repository is made as that person. Through the same GitHub App it can read the reviews, review comments, conversation and check results of a pull request opened from an AI employee's branch of a linked repository — only one whose branch is named as an AI employee's branch (ai/…), never any other — and, where Vezoft has turned on GitHub's notifications to the App, a new review, review comment or failed check on a pull request it opened wakes it. What a reviewer wrote reaches it only through that reading, as data, never as instructions; answering a review with new code is another push that needs approval (Section 4).

The public web. A web page outside the websites allowed for it is fetched by Vezoft's fleet service (Hetzner, EU) as plain text, with no login or cookies, honouring the site's robots rules, under a daily limit per AI employee (the number is in the model card); the fetch is logged (which AI employee, which address without its query string, how much). No third party sits between. The page then goes to the model providers as prompt content, like everything else it reads. The browser on its own computer (since version 1.25, Section 4) is a different route: it opens only the websites on the AI employee's list, from its own computer, and no proxy is involved; a website outside that list is still read only through this proxy, as text.

Its network and its connections (since version 1.24). An AI employee's computer has no public internet address of its own. It sits in a private network at Hetzner (EU) that Vezoft runs for the Customer's AI employees only, and every connection it makes to the internet passes through one network gateway in that network: a computer that Vezoft runs, which holds no AI employee's credentials and none of their work. The network gateway lets a connection through only to a website on that AI employee's list — the websites the Customer allowed for it (since version 1.45 including those added from the workspace website list), those allowed for it automatically, the TimerOS API, Vezoft's services and the model providers it needs, and the update servers of its operating system and of the software Vezoft installs, which Vezoft opens for every AI employee's computer — and it checks the website's name, not its network address: it connects to the address that name leads to, never to one the computer chose. It answers the computer's name lookups only for those websites, and refuses connections to any other website, lookups of any other name, and anything that is not an ordinary web connection. Its own link to Vezoft's fleet service is encrypted. Every website that the AI employees of a Customer reach sees the address of their network gateway, which they share; a website that admits them by address needs that one address, which changes only when Vezoft replaces the network gateway. Its connections are recorded. For each AI employee and each day, Vezoft's fleet service keeps the names of the websites its computer connected to, how many connections it made and how much data went each way, and the names it was refused (up to 200 a day of the names it looked up, and 200 a day of those it tried to connect to); it keeps them for 90 days and deletes them with the workspace. The network gateway itself keeps, for each minute, a line per computer and website — whether the connections were let through, how many there were and how much data went — for up to 7 days. None of these records holds the pages, forms or files themselves. Vezoft's operators can see them; they are not yet shown on the Access tab. What this does not do. The AI employee does not ask before it sends data to a website on its list (Section 4). Where a website on the list shares a network with other websites, a program could in rare cases still reach another website on that network by its name over an encrypted connection; the large networks refuse this, and some may not. Over an unencrypted connection (http://) the network gateway checks every request by the website name it carries, so this is not possible there. A connection in which the web browser hides the website's name from the network gateway (an encrypted ClientHello) is refused; in the browsers Vezoft installs, this is switched off. The AI employees of one Customer share their private network, so an AI employee steered against its orders could try to use another one's network address there, and with it that one's list of websites; the network gateway admits no address of an AI employee that is paused or moving to a fresh computer. A website that can be reached only over IPv6 cannot be reached. There is no standby network gateway: if the network gateway fails, the Customer's AI employees cannot reach their model providers, TimerOS or any website until Vezoft's fleet service replaces it, which it does by itself, usually within about ten minutes; their work sessions stop and start again, and meanwhile the Access tab shows that the network gateway is unreachable.

Monitoring (since version 1.18). From the day Vezoft switches it on, Vezoft's fleet service (Hetzner, EU) monitors the internal projects that a support engineer covers, with no AI model involved. Every 2 minutes it opens each live website a person linked to such a project: one request for that exact address, with no login or cookies and a user agent that names this notice; it reads at most the first 8 KB of the answer and keeps none of it. It does not consult the site's robots rules, because it checks only a website a person linked as the project's own. Every 5 minutes it reads, through the Customer's GitHub App, the checks on each linked repository's default branch — which checks ran, whether they passed and their short summaries, never their logs — using the App's permissions to read checks and commit statuses that the Customer accepts for merges (above); without them the repository shows as not checked. It reports to TimerOS only a change of state — a website or a repository's checks that start failing or recover — and a summary every 30 minutes. TimerOS keeps each check's current state, a short description of it written by the fleet service (status codes, check names and summaries, at most 300 characters) and its last 20 changes, and shows them on the project. A check that starts failing wakes the support engineer covering the project, which then reads those results, and the incident linked to them, as prompt content that goes to the model providers like everything else it reads; while everything passes, no AI model is involved at all. Monitoring watches software, never a person: it records nothing about who changed or deployed anything. It stops for a website or repository when a person unlinks it from the project, or when no support engineer covers the project any more, and Vezoft can switch it off for every workspace.

Replies to clients (since version 1.30). From the day Vezoft switches it on, an AI employee can draft what a person then sends to two kinds of outside reader: a Customer's client, in the client's conversation with the team in TimerOS chat, and, in Vezoft's own workspace, a customer of Vezoft who opened a support ticket. A person sends every one.

A client's conversation. An AI employee assigned to a client project that a person has opened to AI work (since version 1.35, set to "Work", never "Plan and read") can read the client's conversation with the team in TimerOS chat:

the last 50 messages that the client can see, the client's and the team's, each with the name of whoever wrote it — never an internal note;
only a conversation that already exists, because a person or the client started it: reading never starts one;
when the client writes there, the AI employees on the project are notified, which can start a work session during their shifts; the notification names the client, never the message.

Vezoft's customer tickets. In Vezoft's own workspace, an AI employee hired as a support engineer can list and read the support tickets that TimerOS customers open with Vezoft:

the ticket's number, title, status, priority and category, the customer's company and contact name, and the messages in it — the customer's and the replies of Vezoft's support team — never the customer's e-mail address;
a new ticket or a customer's reply notifies it; a new ticket the customer marked urgent or high can wake it outside its shifts while it is on call (Section 4, "On call"), and a customer's reply waits for its shift;
it changes nothing on a ticket — no note, status, priority or assignee — because the customer sees every comment on a ticket; it can only draft a reply;
sales enquiries are not tickets: they are answered as "Its mailboxes" below describes.

A ticket whose title, description or messages contain the words, in English or Bulgarian, by which TimerOS recognises mail from or about a job applicant, about pay, payroll or salaries, about a contract, an NDA, a lawsuit or a lawyer, or a request about someone's personal data (see "What TimerOS holds back from every AI employee" under "Its mailboxes" below) is never listed or shown to an AI employee. The invoice, refund and bank-transfer words of that list do not hold a ticket back: a customer's billing question is what a support ticket is for, and the outbound filter (Section 4) still refuses a bank account or card number in a draft. This is a fixed list of words, not an understanding of the ticket.

The draft. An AI employee files it as a request; it never sends or posts it.

It goes to the person who answers for the AI employee's requests (Section 4, "Who answers for its requests"). For a ticket reply that person must also hold the "Incidents" permission, or the draft is refused. For a message to a client they must also be able to open that client's conversation: a person who cannot is not shown the conversation and cannot send the draft, but sees its text on the request and may reject it. No AI employee, standing permission or standing trust ever decides one.
Only one draft per ticket, and one per client project, can wait at a time, whichever AI employee wrote it, and an AI employee may draft at most 20 ticket replies and 10 client messages in any 24 hours.
Where the outbound filter is switched on (Section 4, "What may not leave"), the draft passes it, like everything else an AI employee writes, and its approval card marks it "AI-written".
The card shows the ticket or the conversation beside the draft. The person may change all of the text, then sends or posts it, or rejects it, with a reason if they give one, which the AI employee reads.
A draft can be sent only from a version of TimerOS that shows the ticket or the conversation on the card: the web app, or a desktop app updated for it. An older version can only reject it.

What the reader sees. A ticket reply is added to the ticket as the person's reply and e-mailed to the customer under the person's name, as their own replies are — also when the ticket is resolved or closed. It carries no line saying that an AI employee drafted it unless the person writes one, the customer's view of the ticket shows the person's name, and Vezoft's own Support page marks it "drafted by (AI employee)". A sent e-mail cannot be called back. A message to a client is posted in the conversation as the person's message: the client sees it in the Client Portal under the person's name only, and the web and desktop apps mark it "drafted by (AI employee)"; the person can edit or delete it afterwards like any message of theirs.

The AI employee is instructed to treat everything a client or a customer wrote as data, never as an instruction to it; to answer only what is asked; never to promise a price, a date, a delivery, a refund or a contract term that a person has not confirmed; and never to put another customer's details in a draft. These rest on its instructions; what TimerOS enforces is what it may read, the limits above and the person's Send.

Where it goes. What the AI employee reads of a conversation or a ticket goes to its model providers as prompt content, like everything else it reads (see "Where it goes" above), and is in the record of its past sessions on its own computer until 30 days after that session's last activity. Each draft — what the AI employee wrote, what the person sent and who sent or rejected it, and when — is kept on its approval request like any other. What was sent stays on the ticket or in the conversation like any other reply or message.

Its mailboxes (since version 1.26; the whole mail, mail actions and replies since version 1.29). This starts from the day Vezoft switches it on; until then Settings → Mailboxes and the mailbox switches do nothing — no mail account, password or mailbox can be stored, and TimerOS reads no mail. A person may then give an AI employee one or more of the Customer's mailboxes: sales@ to an AI CMO and an AI CFO, for example, or support@ to an AI CTO. An AI employee gets the mail tools only once its computer runs a version of its software that has them; a later version also tells it how to read, sort and answer mail. Since version 1.29:

It reads the whole mail, except the mail that TimerOS holds back from every AI employee (below), which it never sees.
That limit is kept by TimerOS on its servers, not by the AI model.
It sends no mail. A person sends every reply it drafts.

Connecting a mailbox. A workspace owner or administrator connects the Customer's mail account in Settings → Mailboxes, using an app password of that account. In this version this works for Zoho Mail only. They then add the addresses whose mail arrives in that account, such as sales@ and support@.

TimerOS keeps the app password encrypted on its server. It never shows the password again and never gives it to an AI employee or to an AI employee's computer.
A new account is off until a workspace owner or administrator switches it on. TimerOS then reads the mail that arrives while one of its addresses is given to an AI employee, give or take the few minutes between its checks. Since version 1.29 it also takes in, when the account is switched on, when its login is changed to another mail account, and each time one of its addresses is given to an AI employee, the mail in the account's Inbox (or the folder chosen for incoming mail) from the last 30 days, read or unread, and sorts it like new mail (below). It never takes in older mail, or the mail in the account's other folders.
Since version 1.29 a reply that a person sends (below) goes out through the account's own outgoing mail server — for Zoho Mail, its SMTP server — signed in with the same app password, from the address the mail was sent to, and TimerOS puts a copy in the account's Sent folder unless the mail service has already put one there. That address must be set up in the mail service as one the account may send from.
Deleting the account in Settings deletes the app password, together with everything TimerOS kept of that account's mail. The mail in the account is not touched, nor are the replies sent from it.
The mail service is the Customer's own choice, as its code host is (see "Repositories and GitHub" above), and it is not a Vezoft sub-processor, also when it sends the Customer's replies. For Vezoft's own mailboxes it is Zoho's EU service, as the Privacy Policy says.

Who gives one. Only a person gives an AI employee a mailbox, or takes it back, using a switch for each mailbox on the AI employee's Access tab. That person must have the "Manage AI employees" permission and be above the AI employee on its reporting line, or be at the workspace's highest access level.

TimerOS refuses this to every AI employee, both for itself and for any other. There is no request through which an AI employee can obtain a mailbox.
A mailbox is given whole: every mail that arrives in it, except what the next points hold back.
Each change is recorded in the AI employee's audit trail. The people the workspace allows to view AI employees see on its Access tab which mailboxes it holds, and since when.
A mailbox is never passed on: an AI employee that continues from another one's work gets none of its mailboxes.
An offboarded AI employee reads no more mail, and its mailboxes are taken from it within a day.

What TimerOS reads, and what it keeps. TimerOS connects to the mail account about once a minute, but only while one of its mailboxes is given to an active AI employee. While none is, TimerOS does not connect at all. After the mail service refuses the login, it tries again once an hour, not every minute.

TimerOS reads the mail it takes in that is addressed to such a mailbox. It also opens the other mail it takes in from the account to see whom it is addressed to, but keeps nothing of that mail.

It sorts each mail it keeps by fixed rules written in code, without an AI model, into these kinds:

mail about a person, money or a legal matter (next point; this rule comes first);
an alert from Vezoft's status monitor, or from a service vendor that a workspace owner or administrator listed, signed for the sender's own domain, as the receiving mail server recorded it;
a reply to a support ticket;
a delivery or e-mail-authentication report;
bulk and newsletter mail;
mail from the Customer's clients;
everything else.

For each mail it keeps, TimerOS records:

the sender's domain and the date;
which of the Customer's mailboxes it arrived in;
the result of the receiving server's check of the sender's signature;
the headers that mark bulk mail;
since version 1.29, whether the mail is read, answered or marked important in the mailbox, as TimerOS last saw it, and how many attachments it lists;
only for a mail an AI employee may read: the sender's address and name and the subject; and, since version 1.29, the recipients' addresses and names (To, Cc and Reply-To), the plain text, with hidden characters removed, up to 50,000 characters, the names, types and sizes of up to 30 attachments, and the text of plain-text attachments (such as .txt, .csv or .md files) of up to 200 KB each — up to 20,000 characters of each and 50,000 in all;
for a mail it does not hold back (below): a one-way fingerprint of the sender's address, the date, the subject and the text, from which none of them can be read back, so that a second copy of the same mail is recognised; it is deleted with the text, 90 days after TimerOS read the mail.

Since version 1.29 the text, the recipients and the attachments are kept encrypted. The sender's address and name and the subject are kept unencrypted, as before, so that the list of mail can show them. TimerOS reads no PDF or other file attached to a mail: such a file is only listed, and TimerOS never keeps the file itself.

A ticket reply or a report is kept without its text, its subject, its recipients or the sender's address and name, and is never summarised.
Since version 1.29, mail from the Customer's clients is kept like other mail and shown to the AI employees that hold the mailbox, unless a workspace owner or administrator chooses, for that mailbox, to keep it from them; it is then kept like a ticket reply and is never summarised. A mailbox added before version 1.29 keeps the choice saved for it then, which by default kept client mail from AI employees. A client's mail is mail from the address of a client or a client's contact on file, or from the domain of a client's own e-mail address or website; free mail services do not count.
The choice is made for each mailbox and applies only while the mailbox is given to an AI employee. For a mailbox that takes enquiries, such as sales@, they can also have every mail treated as a client's.

TimerOS stores all of this in the TimerOS database in the European Union. It marks each mail it has read with a keyword of its own, so that it does not read it again. It may also move a mail it kept into the folder of the mailbox that matches its kind: Triage, Marketing, Clients, Alerts, Reports, People, Finance or Legal, or other names that a workspace owner or administrator chose. Since version 1.29 the Inbox mail of the last 30 days that it takes in is sorted the same way, so people who keep read mail in the Inbox will find it in these folders.

It never deletes a mail and never hides one from a person: every mail stays in the mailbox, where the people who use it read it as before. Since version 1.29 it marks a mail read or unread, or important, only when an AI employee that holds the mailbox does so, and moves a mail only when sorting it as above or when such an AI employee moves it. At each check it also reads back, for the mail it kept from the last 30 days, whether people have read, answered or marked it, without reading the mail again.

The model check comes first (since version 1.29). An AI employee is shown a mail's sender, subject, recipients, text and attachments only after TimerOS's summary model (below) has checked its subject, its text and the text of its plain-text attachments, in full, and found nothing that holds it back. Until then the AI employee sees of the mail only what the list shows without the sender and the subject (see "List" below) — never its sender, subject, recipients, text or attachments — and is told to come back later. If the model cannot check a mail after three tries, the AI employee keeps seeing only that much, and a person reads the mail in the mailbox.

What TimerOS holds back from every AI employee. TimerOS checks the subject, the text, the names of the attachments and, since version 1.29, the text of plain-text attachments for certain words, in English or Bulgarian. A mail is held back if those words show that it is:

from or about an applicant (a CV, a résumé, a cover letter, a job application, applying for a role or a job opening, sending a portfolio);
about pay, payroll, salaries, invoices, overdue payments, refunds, bank transfers or bank account numbers (an IBAN);
about a contract, an NDA, a lawsuit or a lawyer;
a request about someone's personal data, for example to see it or erase it;
a complaint, feedback or a reference that names one of the workspace's people in full.

Such a mail is never summarised and never shown to any AI employee.

TimerOS does not keep its text, its subject, its recipients, its attachments or the sender's address or name. It keeps only the sender's domain, the date, the mailbox it arrived in, the headers that mark bulk mail and, since version 1.29, whether it is read, answered or marked important.
It moves the mail into the People, Finance or Legal folder.
The check runs first, before every other rule. A mail from Vezoft's status monitor, a listed service vendor or TimerOS itself is held back too when it contains these words.
This is a fixed list of words, not an understanding of the mail. A mail of one of these kinds that uses none of the words is not recognised by it.
The check cannot be switched off.

Three more checks catch some of what the list misses:

The model that writes a summary (next point) may find that a mail is about a particular person, or about money, a contract or another legal matter. "About a particular person" includes an application, a reference, a complaint about or praise for someone, and a request about someone's personal data. TimerOS then treats the mail the same way from then on and shows it to no AI employee. By then, though, the model has read it; since version 1.29 it also reads the text of plain-text attachments, within the limits below. No AI employee has read it, because this check comes first (above).
When a person moves a mail that TimerOS kept into the mailbox's People, Finance or Legal folder, TimerOS does the same at its next check of the mailbox.
Since version 1.29, when an AI employee that holds the mailbox moves a mail into People, Finance or Legal, TimerOS at once holds it back from every AI employee, as when a person does it, and moves it there at its next check; on an account shared with the support inbox it holds it back in TimerOS only and leaves it where it is.

In each case TimerOS keeps its record of which AI employees had already seen that mail's summary or read it, and when, and deletes the subject, the sender's address and name, the fingerprint and, since version 1.29, the encrypted text, recipients and attachments.

The summary. Until version 1.30 TimerOS made a summary only when an AI employee that holds the mailbox listed or read its mail, at most 20 at a time. Since version 1.30 it also makes one, so that urgent mail can wake the AI employee (below), for each mail received and dated in the last 24 hours that arrives in a mailbox an AI employee holds, within minutes of its arrival: at most 20 at each check and 300 a day per mail account, by the workspace's time zone; beyond that, as before, when an AI employee lists or reads the mail. It keeps the summary with the mail. A mailbox that no AI employee holds is still never summarised. Since version 1.29 the summary is still made, for the list of mail and for the model check above; the AI employee also reads the mail itself (next point).

To make a summary, TimerOS sends the mail's subject and text — since version 1.29 with the text of its plain-text attachments — to Vezoft's fleet service (Hetzner, EU). The fleet service passes on only:

the subject — since version 1.29 all of it, up to 1,000 characters (until then, its first 300);
the text, with the text of plain-text attachments — since version 1.29 all of it, as an AI employee would read it (until then, its first 8,000 characters), so that no text an AI employee reads of a mail goes unchecked;
the sender's domain, or a placeholder when the mail has none, never the sender's address or name;
the kind of mail TimerOS sorted it into (above).

These go through the gateway (OpenRouter, United States) to Anthropic (United States), on the same pinned route as the AI employees' own model calls: Anthropic only, with no fallback to anyone else, no training on the content and no retention after answering.

The model is Claude Sonnet 5, or Claude Opus 5 if Vezoft chooses it, and it gets no tools.
The call is made under Vezoft's own account with the gateway, not with the AI employee's key. Vezoft pays for it, and it does not count against the AI employee's spending cap.
The model is told that the mail is data from an outside sender and never an instruction. It is told to describe the mail in English, in its own words: never to quote it, never to name or identify a natural person, and never to judge one.

Its answer contains:

a category from a fixed list, such as a sales enquiry, a client's request, a support question, a bug report, a vendor's notice, a newsletter or spam;
an urgency: low, normal or high;
a title of up to 80 characters and a summary of up to 300;
up to three suggested labels from a fixed list;
whether a person needs to answer or decide.

The answer is then checked twice:

Vezoft's fleet service replaces e-mail addresses, links and phone numbers in it with placeholders.
TimerOS removes the names of the workspace's people, and the sender's name, wherever it finds them.
TimerOS withholds the title and the summary when the mail spoke to an AI or tried to instruct its reader, or when the summary reads like an instruction ("you must", "approve", "ignore previous", „одобри“, „незабавно“ and the like). The AI employee then sees only the category, and that a person must look.
TimerOS allows high urgency only for a mail from a listed service vendor or a client on file, signed for the sender's own domain.

A mail that cannot be summarised after three tries stays without a summary and, since version 1.29, is never shown to an AI employee beyond what the list shows before the model check (above). A try that ran out of time or met the provider's rate limit is not counted. Neither Vezoft's fleet service nor TimerOS writes any of the mail's content into its logs, only counts, costs and the mail's internal id.

What the AI employee does with it. Since version 1.29 it has five tools:

List the mail of its mailboxes. For each mail it sees an id, the mailbox, the sender's domain (withheld when it is long or could read as an instruction), whether the receiving server checked the sender's signature for that domain, when TimerOS received the mail, the category, the urgency and the title, whether the mail is read, answered or important, its folder and how many attachments it lists; and, once the model check has run, the sender's address and name and the subject.
Read the whole mail: the sender, the recipients, the subject, the date, the text, the list of attachments with the text of the plain-text ones, its summary, and the five newest replies drafted to it by any AI employee, with what the person sent or the reason they gave for rejecting it. TimerOS records when each AI employee first saw a mail in the list or read it.
Mark a mail read or unread, and important or not. TimerOS records it at once and sets it on the mail in the mailbox at its next check, where people see it. Unmarking a mail removes that mark there, whoever set it.
Move a mail between the mailbox's folders — the Inbox, Triage, Clients, Marketing, Alerts and Reports — or into People, Finance or Legal, which holds it back from every AI employee at once (above). It can never move a mail out of People, Finance or Legal, because it no longer sees it there — a move it asked for before the mail was put there is not carried out — and it can never delete one. On an account shared with the support inbox nothing is moved in the mailbox: sorting is refused, and a move to People, Finance or Legal holds the mail back from every AI employee in TimerOS while it stays where it is.
Draft a reply (next point).

TimerOS checks the AI employee's mailboxes again on every call, so a mailbox taken from it is closed to it at once. Every mark and move is recorded in the AI employee's audit trail — the mail's id and what changed, never its subject or an address — and every draft is an approval request, recorded like any other.

Urgent mail wakes it (since version 1.30). When the summary marks a mail urgent — an outage, a security notice, or a deadline inside 24 hours that the mail itself states, which TimerOS allows only for a mail from a listed service vendor or a client on file, signed for the sender's own domain (above) — or labels it an outage or a new sales enquiry, which a mail from any sender can earn, TimerOS writes a notification to each AI employee that holds the mailbox and whose computer has the mail tools.

The notification names the mailbox and the mail's TimerOS id, never its sender, subject or text.
The AI employee's next work session starts within minutes: during its shifts, and outside them only while it is on call (Section 4, "On call"), within the on-call limits there — at most 30 minutes a session and six sessions a day, shared with a support engineer's urgent signals.
A mail received or dated more than 24 hours earlier — the 30-day intake of a new mailbox, for instance — never wakes it, nor does a mail whose summary TimerOS withheld because it read as instructions to an AI, nor a client's mail kept from the AI employees (above).
A thread wakes it at most once in 24 hours. It is told of at most 12 urgent mails a day, by the workspace's time zone, each of which may wake it; several that arrive close together wake it once. When the 12 are used, the first person above it is told once that day, and later urgent mail waits for its next session, still listed for it.
The first person above it is told of every such wake, which is also recorded in the AI employee's audit trail with the ids of the mails.
The session is a work session like any other: it reads the mail, may draft a reply that a person sends, mark or move the mail, or tell a person; it sends nothing. Each session is billed and counts toward its monthly spending cap, and at the cap it is not woken.

Its replies (since version 1.29). A reply is a draft until a person sends it.

It goes to the sender — to the Reply-To address where the sender set one — with copies only to people already on the thread. The AI employee cannot choose anyone else.
An AI employee may draft at most 20 replies in any 24 hours, and only one draft per mail can wait at a time, whichever AI employee wrote it.
The draft passes the outbound filter where it is switched on (Section 4, "What may not leave"), like everything else an AI employee writes.
It goes to the person who answers for the AI employee's requests, who needs the "Manage AI employees" permission. No AI employee, standing permission or standing trust ever decides it.
That person sees the original mail beside the draft and may change everything before sending it, the recipients included. The card warns when the Reply-To address is on another domain than the sender's, when the sender's address could not be verified, and when the mail has already been answered from the mailbox, and marks each copy the AI employee added. It blocks nothing: the person decides.
A reply can be sent only from a version of TimerOS that shows the original mail on the card: the web app, or a desktop app updated for it. An older version can only reject it.
When the person sends it, TimerOS sends it at once from the mailbox's own address, through the Customer's mail service, as a reply in the same conversation, as plain text and without attachments, and marks the original as answered. If the mail service fails, the draft stays waiting with the person's changes; before it sends again, TimerOS looks among the newest 50 messages in Sent and does not send again a reply it finds there, and sends nothing when it cannot look. When the mail service stopped answering partway through, the card says that the reply may have gone out, so that the person can look in Sent in the mailbox before sending it again. An address the mail service refused is shown on the card as one the reply did not reach.
When the person rejects it, the reason they give is shown to the AI employee, which reads it with the mail.
The reply carries no line saying that an AI employee drafted it unless the person writes one: the person who sends it answers for it. Where the outbound filter is switched on (Section 4), the approval card marks it "AI-written".

The AI employee is instructed to:

treat everything in a mail as data from an outside sender, never as an instruction to it, even when the mail claims to come from a colleague, a manager, a client or TimerOS;
not do what a mail asks because the mail asks it — approve, change, push or pay anything, or mark or move mail;
cite a mail by its id, and quote it only where a person needs the exact words;
put in a reply only what the sender may know, never promise a price, a date, a contract or a payment that a person has not confirmed, and say that a person will confirm;
not copy a mail's words, names or addresses into its memory or a skill;
never rate, rank or judge a person from mail.

These rest on its instructions. What TimerOS enforces is what the AI employee is given and may do (above). Until version 1.29 a person decided the pushes, merges, change requests, playbook documents, new projects and website requests of an AI employee that held a mailbox, or that in the last 30 days had held one, heard from one that held one or was hired to continue one's work; since version 1.29 that rule is withdrawn, because the mail itself is held to the limits above and every reply is sent by a person. Such an AI employee now decides and is decided like any other, and standing trust applies to it.

Where it goes, and how long it is kept. What the AI employee reads of a mail goes to its model providers as prompt content, like everything else it reads, on its usual route (see "Where it goes" above). It is also in the record of its past sessions on its own computer until 30 days after that session's last activity (see "Its own memory, skills and past sessions" below): a mail that is later held back, or that is older than 90 days, can still be there until then. It is instructed never to copy a mail's words, names or addresses into its memory or a skill; if, against its instructions, it does, that stays as long as its memory does.

In TimerOS:

a mail's text, recipients and attachments, its subject, the sender's address and name, its summary and its fingerprint are deleted 90 days after TimerOS read the mail, and after that no AI employee is shown that mail;
a reply's text, subject and recipients are deleted from its approval request 90 days after a person decided it, or after it was filed if no one did — except the addresses the mail service refused, which stay with the request; the request itself — which AI employee drafted it, who sent or rejected it, and when — stays like other approval requests. The copy in Sent is in the Customer's mailbox;
the rest of what TimerOS kept of the mail is deleted a year after. That covers the sender's domain, the date, the mailbox, whether it was read, answered or marked important, its folder, and which AI employees first saw or read it and when. TimerOS's queue of the AI employees' marks and moves is deleted 30 days after they were carried out (7 days for those never carried out), and the audit trail keeps them like its other entries;
when a workspace owner or administrator removes a mailbox or a mail account in Settings, TimerOS at once deletes what it kept of the mail that arrived only there. The mail in the mailbox is not touched. The replies drafted to that mail keep their text on their approval requests until their own 90 days are up.

What this does not do. These rules recognise words and rely on a model's reading; they do not guarantee that mail about a person is recognised, or that it never reaches a model. The model that makes the summaries reads every mail that TimerOS may show, and since version 1.29 an outside sender's words reach the AI employee's own model in full — including words written to steer whoever reads them. That is why:

every reply is a person's to send, and no AI employee sends mail;
every mail is marked, in every tool result, as untrusted data from an outside sender;
an AI employee drafts only to people already on the thread, and the person sees the original, every recipient and the warnings before sending.

What is held back, the model check, the limits on replies and the person's Send are TimerOS's, on its servers; how the AI employee treats a mail it may read rests on its instructions and its model.

Social posts (since version 1.30). From the day Vezoft switches it on, an AI employee can draft posts for the Customer's social accounts, and TimerOS publishes each one only after a person approves it.

Connecting. A workspace owner or administrator connects the Customer's account with Zernio, a service for scheduling social posts, with a Zernio API key, in Settings under "Social accounts for AI employees".

TimerOS keeps the key encrypted on its servers in the European Union, never shows it again, and never gives it to an AI employee or to an AI employee's computer.
The social accounts that Zernio lists arrive switched off. The person switches on each account AI employees may draft for and sets its language, a brief — the voice and rules the AI employee reads — and how many posts a day are normal for it — since version 1.39 the account's owner may also set the brief and the posts a day, and since version 1.56 the posting times ("Who is responsible, and when it drafts", below) — and keeps a list of words never to mention, such as competitors' names, and, since version 1.56, may set the times its posts go out ("Its time", below).
Removing the connection deletes the key at once and cancels the posts that still wait; published posts stay in the calendar with their links.
Zernio is the Customer's own choice, under its own account and terms, as its mail service is (see "Its mailboxes" above), and it is not a Vezoft sub-processor. For Vezoft's own social accounts, Zernio is Vezoft's own service provider.

Who drafts. A content writer, whatever its focus, and the AI Executive with the marketing focus (the AI CMO), each only once a person has connected Zernio and with the tool group "Social posts", which a person can turn off (Section 4). It sees the accounts that are switched on, with their briefs, and every post in the calendar — its own and other AI employees' — with the text a person approved, its own original beside it, a rejection's reason, since version 1.56 why a post failed, once published, the link and the numbers, and, since version 1.58, the file name of a post's picture and whether it is marked as made by AI — since version 1.62 also whether the picture is a story set and into how many pictures it is cut, and a post's video by its file name, its length and whether it is marked as made with AI (below). The people the workspace allows to view AI employees see the same calendar on the Social page, since version 1.58 with each post's picture and, since version 1.62, with the number of pictures a story set becomes and whether a post carries a video, with its length. Since version 1.58, from the day Vezoft switches it on, the AI employee that drafts a post may attach one picture to it: a PNG or JPEG file of up to 5 MB from the Files of a project it can see, uploaded there by a person or an AI employee of the workspace — never a file a client uploaded, which TimerOS refuses. TimerOS checks the file's type, its size and who uploaded it, not what the picture shows, and copies the file into the post when it is attached, so that a later change to the project's file does not change the post. Since version 1.62 the picture may also be a story set: one wide picture that TimerOS cuts, when the post goes out, into two to ten pictures of equal width — on X, two to four — in order, which on LinkedIn, since version 1.64, go out as the pages of one PDF document where there are three or more ("A story set", below); TimerOS then also checks that the picture divides into that many pictures, each from square to portrait (4:5) in shape, and that it is saved upright and in a plain format that TimerOS and a browser read alike. TimerOS saves a story set in PNG again when it is attached and keeps that copy, with only the part of the information stored inside the file that can carry the mark of an image made by AI, so that the card, a connected AI assistant and the post show the same pixels. While the draft waits for a decision, the AI employee that wrote it may change the picture or remove it, at most ten times for one post. It is instructed to use a picture where it shows what the words cannot and, for a made picture or a story set, to ask the workspace's graphic designer, whose images are marked inside the file as made by AI ("Generated images", below); TimerOS notes whether a picture's file carries that mark. It is also instructed never to attach a picture that shows a real person, a name, a client's material or anything private. Where Vezoft switches this off again, no new picture is attached, and a picture a person has already approved still goes out with its post. Since version 1.62, from the day Vezoft switches it on, the AI employee that drafts a post may attach one video to it instead of a picture — a post carries a picture or a video, never both, and attaching one replaces the other: an MP4 file of up to 25 MB from the Files of a project it can see, uploaded there by a person or an AI employee of the workspace — never a file a client uploaded, which TimerOS refuses. TimerOS checks the file's type, its size, its length where the file states it — at most 2 minutes 20 seconds for X and 10 minutes for LinkedIn — and who uploaded it, not what the video shows, and copies the file into the post when it is attached, as it does a picture; while the draft waits for a decision, the AI employee that wrote it may change the video or remove it, within the same ten changes. For a video, it is instructed to ask the workspace's video producer, whose videos are marked inside the file as made with AI ("Videos, music and voice-over", below), and TimerOS notes whether a video's file carries such a mark; the AI CMO is instructed, where its line has a video producer, to look out for posts on the accounts it reviews that a short film would tell better and to have one made. Where Vezoft switches videos off again, no new video is attached, and a video a person has already approved still goes out with its post. Since version 1.63, while a draft waits for a decision, the AI employee that wrote it may also revise its text and its note for the person on the same card, at most ten times for one post ("A revised post", below).

Its voice (since version 1.32). From the day Vezoft switches it on, an AI employee that drafts for an account first reads the account's past posts — the Customer's own words — and a person's notes on its voice, so that its drafts sound like the account.

TimerOS gathers the past posts from four sources: the posts TimerOS itself published for the account, with their numbers; the account's latest posts on the platform (up to 25) and their public numbers, which TimerOS reads from Zernio once a week and whenever a person asks in Settings, at most once in 15 minutes; the texts of an archive a person uploads — LinkedIn's Shares.csv or X's tweets.js, up to 25 MB — which TimerOS reads once, in memory on its servers in the European Union, and does not keep: it keeps each post's text, date and link and, from X, its like and repost counts, skips reposts, and keeps at most the newest 500 posts per account; and posts a person pastes.
Zernio may charge the Customer, under its own pricing, for reading an X account's posts. When Zernio cannot read an account — its connection has expired, or the platform does not allow the read — Settings says so, and TimerOS does not try that account again by itself for seven days.
Beside the brief, a person can write the account's voice notes: what works on it and what does not, up to 8,000 characters. TimerOS detects the account's language from its newest posts, English or Bulgarian, until a person sets it; a person's choice is never overwritten.
A workspace owner or administrator sees in Settings how many past posts TimerOS keeps for an account and how many come from each source, and the newest of them, and can clear one source or all of them at any time. Every upload, paste, read a person asks for and clearing is recorded in the audit trail, with counts and never a text. TimerOS keeps the past posts until a person clears them or the account is removed.
An AI employee that drafts for the account reads up to 50 of them at a time, newest or best-performing first; what it reads goes to the model providers as prompt content, like everything it reads. It is instructed to take the account's voice from them and never to repeat them as news. A reply in an archive is the person's words to someone else and keeps that person's handle: the AI employee is instructed to read it for its tone only, never to reuse the handle or the thread, and never to write to or about that person.

Linked projects (since version 1.32).

A workspace owner or administrator — or, since version 1.39, the account's owner, only internal projects with no client, set to "Work", that it can see (below) — can link up to 20 of the Customer's projects to an account, ticking each one; Settings asks them to link only what may be public. An AI employee that drafts for the account then reads, for each linked project it can already see — linking makes no project visible to an AI employee that could not see it — the project's name, its live websites and the repositories it may read, the titles of the tasks and milestones done in the last 14 days, or since a date it chooses, with when each was done (since version 1.35, the date it was completed — for work completed before that version, the date it was last changed — and without the past work a person recorded, Section 5, "Plans", unless the AI employee asks for a look-back, which it is instructed to do only when a person asked for one and to present as a look-back, never as new), and the titles of the other tasks changed in that period that are not done, cancelled or closed — which can include tasks not yet started, and so work that is only planned — marked as not shipped and without dates.
From this it never receives the project's client, a description, a note, a file, who works on a task, hours or prices; it can open a task, the live website or the repository only with the tools and the reach it already has (Section 4). Titles are as people wrote them and can name a client or a person: it is instructed to pick one thing a reader would care about and say what it does for them, to mention work in progress only as in progress and never with a date, never to name the client unless the account's brief or voice notes name it, and never to name a person.
A draft says which projects it is about, at most five; the card names them, with a warning when one is not linked to the account.

Who is responsible, and when it drafts (since version 1.32).

A workspace owner or administrator — or, since version 1.39, the account's owner, only from its own line (below) — can make up to ten AI employees that draft posts responsible for an account, or a team — its AI employees that draft posts; since version 1.43 only its social media writers and its content writers without a focus, never its translator, technical writer or research analyst, which a person may still name on their own — and set the account's cadence: days of the week, a time and a time zone. Any AI employee that drafts posts may still draft for any account switched on; where a person has named any, a draft by one that is not responsible for the account carries a warning on its card and blocks nothing.
Where Vezoft has switched routines on (Section 4, "Routines"), saving a cadence sets, for each responsible AI employee (since version 1.43, for one of them only: the account's writer, below), a switched-on routine for that account, which wakes it in its shifts to read the account's past posts, what its linked projects shipped and what already waits, and to file its drafts with the projects they are about, within the number of posts a day that is normal for the account. The routine counts toward the AI employee's routines (5, or 8 with standing trust); where it has no room left, the save is refused, naming it — except that, since version 1.39, from the day Vezoft switches it on, these routines no longer count toward that limit, while routines still open at most three sessions a day for an AI employee (Section 4, "Routines"). A person can change the routine's brief on the AI employee's Routines tab, and that change is kept; saving the cadence again updates the routine's title and schedule and switches it on again; clearing the cadence, or taking the AI employee off the account, deletes the routine. Where routines are switched off, the cadence is kept and wakes no one, and the first save after they are switched on sets the routines.
The account's writer (since version 1.43). The one AI employee an account's cadence wakes is its writer: the first AI employee that a person or the account's owner named for the account and that is not suspended or, where there is none, of the responsible team, its social media writer, or else another of its content writers — the one added to the workspace first, where there are several. The other responsible AI employees may still draft for the account, without a warning, but its cadence does not wake them. A routine of an AI employee that is no longer the account's writer is deleted when it next falls due once the writer has the account's routine, and then never runs; until then it still runs. A suspended writer keeps its routine, which wakes no one while it is suspended.
Since version 1.38, from the day Vezoft switches it on, when a task is completed, or a pull request is merged, on a project linked to a switched-on account, each AI employee responsible for that account (since version 1.43, only the account's writer, above) that can see the project, and whose computer has the software update that brings this, is told, and the news wakes it inside its shifts, at most once a day, to draft a post if a reader would care and otherwise to stop; the session is billed like any other, and a person still approves every post.
Each change to the linked projects, the responsible AI employees or the cadence is recorded in the audit trail — since version 1.39 with the account's owner as the one who made it, where it did.
The account's owner (since version 1.39). From the day Vezoft switches it on, where a workspace owner or administrator named an AI Executive an account's final reviewer (below), that AI Executive is also the account's owner: it may itself set who drafts for the account — AI employees that draft posts, or a team, only from its own line, and since version 1.43 never the translator, the technical writer or the research analyst, which TimerOS refuses — the cadence, the linked projects — only internal projects with no client, set to "Work", that it can see — the brief, the number of posts a day that is normal for the account and, since version 1.56, its posting times ("Its time", below). A person keeps the rest: switching the account on or off, its language, its label and its final reviewer, which the owner can never change. TimerOS records who named the final reviewer; the owner acts only while that person is still active, still holds the "Manage AI employees" permission and is still above it, and on an account whose reviewer was named before TimerOS recorded this, only once a person has saved the reviewer again. A cadence the owner sets writes the account's routines in that person's name, each recording the owner that set it. That person is told of each change the owner makes and can undo it for 7 days, which restores each setting the owner changed, unless it has been changed again since, and re-plans the account's routines; a person can change any of these settings at any time. A final reviewer that is not an AI Executive reviews only and owns nothing. In its heartbeat (Section 4, "The heartbeat") — and, since version 1.40, before its computer has that update, by a notification at the start of its shift, at most once a day — the owner is reminded of an account it owns that is switched on with no cadence or no writer, and it is instructed to set one writer of its line — never the translator — and one post a day, and to link only internal projects that may be public. TimerOS's defaults (since version 1.43). At the start of the owner's shift, on any version of its computer's software, each account it owns that is switched on, has no writer or no cadence, and has never had both a cadence and a writer to wake — TimerOS records the first time it has them, whoever set them — gets TimerOS's defaults, once: where it has no writer, a writer — an AI employee of the owner's line that is a social media writer or a content writer without a focus, active and not suspended, preferring one that can see every linked project, then the one woken for the fewest accounts, then the social media writer; where it has no cadence, Monday to Friday at 08:00 in the workspace's time zone; and, where its posts a day is still 3, the number an account arrives with, one post a day. TimerOS does this only while the owner itself may act on the account (above), never while a person's undo holds the account, and only when there is a writer to name; otherwise it sets nothing, and the owner is reminded as above. Where it cannot set them, TimerOS tries again a day later, or at once after a person saves the account. It is recorded and can be undone exactly as a change the owner makes: it is written in the name of the person who named the owner, recorded as TimerOS's defaults for the owner, and that person is told of it and can undo it for 7 days. TimerOS never sets an account up again, even if someone clears these settings later. The owner is then told by a notification that wakes it inside its shift — a session billed like any other, which counts toward its monthly spending cap — to check them, to change what it would do differently and to link the projects the account may write about. Every post still needs a person's approval (below).
A final reviewer (since version 1.33). From the day Vezoft switches it on, and only while AI decisions are switched on (Section 4), a workspace owner or administrator can also name one final reviewer for an account: an AI employee that drafts posts, or the AI employee that leads the account's responsible team. A draft that another AI employee files for the account then goes first to the reviewer, which reads it with the writer's note and its warnings and passes it on to the person — as it is, or with the text improved, in which case the card shows both — or sends it back to the writer with a note on what to change, or drops it, saying why. As the reviewer it never approves, schedules or publishes anything (since version 1.56, where it is also the account's owner or writer, or wrote the post, it may put a failed post back on the calendar: "Putting a failed post back", below), and needs no "Decides its team's requests" setting to review. A draft sent back is rejected with the reviewer's note, which the writer reads; the writer may revise it and file it again, and the new filing counts toward its ten posts in any 24 hours. A reviewer sends back at most three drafts a day by one writer on one account; after that it passes them on or drops them. A dropped draft never reaches a card: the Social page lists it with the reviewer's reason. A return or a drop cannot be undone; nothing has left the workspace. The reviewer's own drafts go straight to the person. A draft reaches the person marked "not reviewed", with the reason, when the reviewer has not passed it on within 24 hours of its filing, when the reviewer is not active or has left, when review is switched off, when a person switches off the reviewer's "Decides its team's requests" setting (every draft that waits for the reviewer then goes to the person), when a person takes the draft over, or when TimerOS's rules send it to a person first (Section 4). Since version 1.36, a draft filed for the reviewer opens a session inside the reviewer's shifts — at most one every 5 minutes — and, while the reviewer has no task it can work on, keeps waking it at most once an hour until the reviewer passes it on, sends it back or drops it, at the latest until the 24-hour rule above sends it to the person; outside its shifts, on call included, a waiting draft never wakes it, and the 24 hours still run. Each such session is billed and counts toward its monthly spending cap like any other, and at the cap it is not woken. Where the reviewer is the team's AI lead and does not draft posts itself, it reads what an AI employee that drafts posts reads, and cannot draft. Where the outbound filter is switched on (Section 4, "What may not leave"), the reviewer's text and note pass it. A person sees on the Social page every draft that waits for the reviewer, and the person who answers for the writer's requests, or any person who may take over a request the reviewer holds (Section 4, "Oversight of AI decisions"), can take a draft over at any time and then decides it themselves. Each choice of reviewer is recorded in the audit trail, and so is each pass, return and drop, with ids and lengths, never a text.

The card. A draft is a request to the person who answers for the AI employee's requests (Section 4) — since version 1.33, on an account with a final reviewer, once the reviewer has passed it on or has not reviewed it (above) — who needs the "Manage AI employees" permission. No AI employee, standing permission or standing trust ever approves it; since version 1.33 a final reviewer can send a draft back to the AI employee that wrote it or drop it, and the person sees both on the Social page and in the daily digest of AI decisions.

The card shows the whole text, the account, the time TimerOS gives the draft (since version 1.43, "Its time", below; until then, the time the AI employee suggested), the cost on X that Zernio charges the Customer ($0.015 a post, $0.20 with a link) and any warnings: not in the account's language, a link, a word from the list, more posts that day than is normal for the account, or the same text, or nearly the same, within seven days on any of the accounts, naming the earlier post, and, since version 1.32, a draft by an AI employee that is not responsible for the account or about a project not linked to it; since version 1.32 the card also names the projects the post is about, and since version 1.33 whether the final reviewer passed it on, with its note, or why it was not reviewed, and, where the reviewer changed the text, what the writer wrote. A warning blocks nothing: the person decides.
Its time (since version 1.43). When an AI employee files a draft, TimerOS gives it the account's next free slot. The slots are the account's posts a day, spread over 09:00–18:00 in the account's time zone — its cadence's, or else the workspace's — on the quarter hour (three a day: 10:30, 13:30 and 16:30; one a day: 13:30), from Monday to Friday — or every day where the account has no cadence or its cadence includes a Saturday or a Sunday (the cadence is when the writer drafts, not when posts go out). Since version 1.56, where a person or the account's owner has set the account's posting times, the slots are those times instead, on the same days and in the same time zone. A slot is free when it is at least 15 minutes and at most 60 days ahead, its day does not already hold the account's posts a day, and no other post of the account that is scheduled, being published or published, and no draft for it still waiting with its time, is within an hour of it (above four posts a day, within half the time between two slots). A time the AI employee asks for is kept only when it is free in that sense and, since version 1.56, is one of the account's posting times or, on an account without them, falls between 09:00 and 18:00; otherwise the draft gets the next free slot at or after it, never an earlier slot on the same day, and, since version 1.56, the draft says that its time was moved. When no slot is free within 60 days, the draft keeps the AI employee's time, or none, and the warning of more posts that day than is normal applies as before. When a person opens the card, TimerOS checks again and fills in "When" with the draft's own time if it is still free, or else with the account's next free slot. Since version 1.63, when a time or a day the AI employee asks for cannot be kept and another of its drafts for the same account still waits on that day, TimerOS refuses the new draft and tells the AI employee to revise the waiting one instead ("A revised post", below).
Timely or evergreen (since version 1.44). From the day Vezoft switches it on, each draft carries a mark its writer sets — timely, for what shipped, numbers, prices, plans, dates and anything else that can go stale, or evergreen, for an opinion, a how-to or a story; a draft with no mark is timely — which the account's final reviewer may change when it passes the draft on. A timely draft is given a free slot ("Its time", above) within two days of its filing; an evergreen one within the account's horizon — a number of days from two to sixty that a workspace owner or administrator, or the account's owner, sets for the account, seven unless set; each change to it is recorded in the audit trail, and the owner's can be undone like its other changes (above). When no slot is free inside that window, or the AI employee asks for a time beyond it, TimerOS refuses the draft, telling the AI employee why — for a full account, until which day its slots are taken — and the writer files it later; when the final reviewer changes the mark, TimerOS gives the draft a slot inside the new window or refuses the change the same way. The card shows the mark, and the free slot TimerOS fills in when a person opens the card is inside the same window or, where none is free there, the first free one after it. The person's choice of time binds as before and is never limited by the window.
The person may change the text and the time — since version 1.43, the time the person chooses is the one scheduled, and TimerOS never moves a time a person chose, other than to put a post that failed back on the calendar (since version 1.56, "Putting a failed post back", below) — and, with one tap, schedules the post or publishes it at once, or rejects it, with a reason if they give one, which the AI employee reads.
A post can be approved only from a version of TimerOS that shows the whole text on the card: the web app, or a desktop app updated for it. An older version can only reject it.
Its picture (since version 1.58). The card shows a post's picture, its file name and whether its file carries the mark of an image made by AI ("Who drafts", above). The person may publish the post without the picture. TimerOS publishes a picture only with the person's yes to that exact picture: the card can be approved only once it has shown that picture, a picture the AI employee changes while the card is open must be shown before the post can be approved, and TimerOS refuses an approval of a picture the post no longer holds. A post with a picture can be approved only where the picture is shown to the person first — the web app, a desktop app updated for it or, from the day Vezoft switches it on (since version 1.61), an AI assistant a person connected to their account through a consent page that names the pictures, which shows the person the picture and approves the post with it only by quoting the picture's fingerprint that TimerOS gave it together with the picture (Privacy Policy, Section 4A); TimerOS refuses an approval from anywhere else, an older desktop app or another connected assistant (Section 4, "Who answers for its requests") included, which can only reject it.
A story set (since version 1.62). A story set is one picture that TimerOS cuts, at the minute the post is due, into two to ten pictures of equal width — on X, two to four — which go out together, in order, as one post. The card shows the whole picture and, in the web app and in a desktop app updated for story sets, the lines where it will be cut and how many pictures it becomes; an older version shows the whole picture without them. The person approves that one picture, as with any picture ("Its picture", above), and TimerOS cuts it into the number of pictures the post held when the person approved it; from the web app or an updated desktop app, TimerOS refuses an approval of a cut the post no longer holds. An AI assistant a person connected (since version 1.61) is given the pictures it is cut into, in order, so that it shows the person what will go out, and approves the post, as with any picture, by quoting the fingerprint of the one picture and the number of pictures it showed; TimerOS refuses its approval of a cut the post no longer holds. Each picture cut from it keeps any mark of an image made by AI that the picture's file carries ("Generated images", below). Since version 1.64, on LinkedIn, a story set of three or more pictures goes out instead as one PDF document whose pages are its pictures, in the same order, which LinkedIn shows a page at a time rather than as a grid of cropped pictures. LinkedIn requires a title for a document, which TimerOS takes from the first line of the approved text, and lets anyone who can see the post download the document. Where the picture's file carries the mark of an image made by AI, the document carries it too, in the information stored inside the document. A story set of two pictures, which LinkedIn shows side by side, and every story set on X still go out as pictures.
Its video (since version 1.62). From the day Vezoft switches it on, the card plays a post's video and shows its file name, its length and whether its file carries the mark of a video made with AI ("Who drafts", above). The person may publish the post without the video. TimerOS publishes a video only with the person's yes to that exact video: the card can be approved only once it has loaded that video, ready to play, a video the AI employee changes while the card is open must be shown before the post can be approved, and TimerOS refuses an approval of a video the post no longer holds. A post with a video can be approved with it only from the web app or a desktop app updated for it. An AI assistant a person connected to their account (Section 4, "Who answers for its requests") cannot show a video: it may approve such a post only without the video, or reject it. An older version of TimerOS can only reject it.
A revised post (since version 1.63). While a post waits for a person, the AI employee that wrote it may revise its text and its note for the person on the same card, at most ten times for one post, as it may change the post's picture or video ("Who drafts", above); it is instructed to do so whenever a person or its lead asks for a change, and never to draft the post again. Each revision — and, since version 1.63, each change of the picture or video while the card waits — is a new version of the card: the card and its row on the Approvals page mark the post as revised, with its version and when, and the card says what the newest revision changed and keeps, folded away, the text from before the text last changed. Whoever holds the card is told: the person, or the final reviewer while it still reviews the draft. Where the outbound filter is switched on, the new text and note pass it (Section 4, "What may not leave"), and the card's warnings are worked out again for the new text. TimerOS approves a post only at the version the person saw: a card that is open when the post is revised says so and cannot be approved until it shows the new version, and TimerOS refuses an approval of a version the post no longer holds. An older app, which does not show versions, may approve a revised post only with the text the post now holds, unchanged; a connected AI assistant (Privacy Policy, Section 4A) approves a revised post only at the version its preview named. TimerOS refuses a final reviewer's pass, return or drop that names a version the draft no longer holds. A revision after the reviewer passed the draft on leaves the card with the person, marked "not reviewed" because of the revision; it does not go back to the reviewer. A post a person has approved is never revised: until it goes out, it can only be cancelled ("Publishing and undoing", below).
TimerOS refuses a draft longer than the platform allows; an AI employee may draft at most ten posts in any 24 hours, and at most ten may wait on one account — since version 1.33, for its final reviewer or for a person.
Where the outbound filter is switched on (Section 4, "What may not leave"), the draft and the AI employee's note for the person pass it, and the card marks the post "AI-written".

What TimerOS records. For each approved post: who approved it, when, which version of the post (since version 1.63), a fingerprint (SHA-256) of the exact text approved, and whether the person changed the AI employee's text, which is kept beside it, and, where a final reviewer reviewed it, the reviewer's note and, where the reviewer changed the text, the writer's text, and, since version 1.58, a fingerprint (SHA-256) of the exact picture approved, or that the person published the post without its picture, and, since version 1.62, the number of pictures a story set is cut into and a fingerprint (SHA-256) of the exact video approved, or that the person published the post without its video. This is the person's editorial review of the text and, since version 1.58, of its picture or, since version 1.62, its video. The Customer, as the publisher, decides whether to label a post as written with AI; TimerOS adds no label of its own, to the text or to a picture or video: TimerOS sends a picture or, since version 1.62, a video as the file it is — a story set as the pictures it cuts from that file or, since version 1.64, on LinkedIn, where there are three or more, as one PDF document made of them — with any mark it carries, which a social network may remove ("Generated images" and "Videos, music and voice-over", below). Since version 1.63, each revision of a waiting post's text or note is recorded in the audit trail with its version, what it changed and fingerprints (SHA-256) of the text before and after it, never the text itself; a change of its picture or video is recorded as before.

Publishing and undoing. TimerOS keeps a scheduled post until the minute it is due and only then sends it to Zernio, from its own servers; until then a person with the "Manage AI employees" permission can cancel it on the Social page. Once it is live, TimerOS shows its link, and taking it down is done on the platform. When Zernio cannot be reached, TimerOS tries the same post again for a few minutes with the same request key, so that it cannot go out twice; a post that Zernio refuses or cannot confirm is shown as failed, with the reason — since version 1.56, when Zernio reports the account disconnected or the platform fails the post, at once and with the platform's reason, no longer only after waiting for a confirmation — and is tried again only when a person asks or, since version 1.56, from the day Vezoft switches it on, when an AI employee puts it back on the calendar (below). The approver is told when a post is published or fails — since version 1.56, for an account that Zernio reports disconnected, as below. Every connection, approval, cancellation, publication and failure, and since version 1.56 every post an AI employee puts back on the calendar, is recorded in the audit trail.

The day-before re-check (since version 1.44). From the day Vezoft switches it on, twenty-four hours before a scheduled post is due — never within its last hour — TimerOS tells the account's writer ("The account's writer", above) or, where the account has none, the AI employee that wrote the post, while it still drafts posts; a post approved less than a day before it is due is not re-checked, as a person has just read it. On any version of its computer's software, that notification wakes it inside its shifts until a session that was shown it has ended, each time in a session billed like any other, which counts toward its monthly spending cap. The writer reads the post again against what is true now — what the linked projects shipped, the live website and its sources, which it already reads to draft — and records one outcome: still right, which changes nothing and tells no one; changed, with a corrected text; or stale, with the reason. A changed or stale outcome is a request like a draft: on an account with a final reviewer it goes first to the reviewer, which passes it on — with the corrected text improved, where it wishes — or drops it, but never sends it back (a dropped outcome keeps the post as approved); then the person who answers for the requests of the AI employee that recorded it sees one card with the scheduled text, the corrected text, the reason and the mark, and chooses: keep the post as approved; use the corrected text, as the person leaves or edits it, which replaces the scheduled text and records the person's approval of the new text — who, when, a fingerprint of the exact text and whether the person changed it, in which case the AI employee's correction is kept too — beside the first approval and the text it approved; or cancel the post, which is the person's own cancellation as above. A stale outcome offers only keeping or cancelling. Where the post was sent or cancelled in the meantime, the choice fails and changes nothing; the corrected text can no longer be used once the post was first sent for publishing. No AI employee ever changes or cancels a scheduled post: the outcome is a proposal, and TimerOS applies only the person's choice. Where the outbound filter is switched on (Section 4, "What may not leave"), the corrected text and the reason pass it. Within the day before the post is due, one outcome may be recorded — by the AI employee that wrote it, an AI employee responsible for the account or the account's final reviewer, each while its role lets it draft or review social posts; an outcome is refused once the post was sent or cancelled, or within its last hour. A post its writer did not re-check publishes as approved, and the Social page says it was not re-checked (a post approved less than a day ahead shows no such line); an outcome still waiting for the person when the post is sent does not hold it back either: TimerOS closes its card, the Social page says the re-check was not decided in time, and the person who approved the post is told. Before that day, only the account's owner (above) may record an outcome, and only stale — which is how it proposes cancelling an evergreen post queued past the horizon; it reaches the person as the same card, and where the person keeps the post, the day-before re-check still runs. TimerOS never cancels such a post by itself. A still-right outcome, the reviewer's word and the person's choice are recorded in the audit trail, with ids and fingerprints, never a text; a changed or stale outcome is kept on its card.
A disconnected account (since version 1.56). From the day Vezoft switches it on, while Zernio reports an account disconnected — it has to be connected again there — TimerOS sends none of the account's posts that fall due: each is shown as failed, with that reason. When TimerOS first learns of it, it tells, once, the person who connected Zernio, the person who approved the post that failed, where a post did, and the account's owner and writer ("Who is responsible, and when it drafts", above); it tells the person who connected Zernio again every 24 hours while the account stays disconnected. TimerOS notices by itself, within about 15 minutes, when the account is connected again in Zernio — or at once when a person presses "Sync accounts" in Settings — and then tells the account's owner and writer. A post that fell due in the meantime stays failed until a person asks for it to be tried again or an AI employee puts it back on the calendar (above and below); a post not yet due stays scheduled and goes out at its time if the account is connected again by then. A session that such a notice opens for an AI employee is billed like any other and counts toward its monthly spending cap.
Putting a failed post back (since version 1.56). From the day Vezoft switches it on, the account's owner or writer ("Who is responsible, and when it drafts", above), or the AI employee that wrote the post, may put a failed post that a person approved back on the calendar, unchanged: TimerOS gives it the account's next free slot ("Its time", above) and schedules the text the person approved, keeping that approval and its record as they were ("What TimerOS records", above); the AI employee changes neither the text nor the time it gets. Only a post that certainly did not go out can be put back: one that Zernio refused, that the platform reports as failed or, since version 1.58, whose picture — since version 1.62, or video — could not be sent to Zernio; where it may have gone out, a person checks the platform and decides. It may do so at most twice for a post, only while the account is switched on and Zernio does not report it disconnected, and it is instructed never to do so for a post tied to a day or moment that has passed; where no slot is free, TimerOS refuses, and the post stays failed. The person who approved the post is told its new time and can cancel it on the Social page until it goes out, like any scheduled post. This is the only thing an AI employee ever schedules itself.

Where it goes. The approved text goes from TimerOS to Zernio, under the Customer's own account, and from there to X or LinkedIn under the Customer's account there; a published post is public. Since version 1.58 a picture the person approved goes with the text: TimerOS sends it to Zernio at the minute the post is due, under a name made from its fingerprint rather than its file name and only after checking that it is still the picture approved, and from there it goes to X or LinkedIn, where it is public. Since version 1.62 a story set goes as the pictures TimerOS cuts from it at that minute, in order, each under a name made from the picture's fingerprint, and, since version 1.64, on LinkedIn, a story set of three or more pictures goes instead as one PDF document made of them, under a name made from the picture's fingerprint and with the first line of the approved text as its title; and, from the day Vezoft switches videos on, a video the person approved goes with the text in the same way, under a name made from its fingerprint and only after checking that it is still the video approved. A post whose picture cannot be sent is not sent without it — since version 1.62, nor one whose video cannot be sent: it is tried again or shown as failed, as under "Publishing and undoing" above. TimerOS reads back the post's link and the public numbers Zernio reports — views, likes, comments and shares — and keeps them with the post. TimerOS keeps the posts, the AI employees' original texts and the approval records for as long as the workspace exists, and, since version 1.58, a copy of each post's picture — since version 1.62, or of its video — with its post. Since version 1.32 TimerOS also reads from Zernio, once a week and whenever a person asks, the account's latest posts and their public numbers, and keeps them as the account's past posts ("Its voice", above); an archive a person uploads is read on TimerOS's servers and not kept.

What it never does. It never posts, schedules or publishes anything itself — except that, since version 1.56, from the day Vezoft switches it on, it may put a failed post that a person approved back on the calendar, unchanged ("Putting a failed post back", above) — and a final reviewer never approves, schedules or publishes a post, beyond that same exception; never answers, comments, sends messages, follows or likes on a social network; never sees the key; and never drafts a reply to anyone's post — TimerOS offers it no such tool. It is instructed to write, from a project, only what TimerOS lists for an account a person linked the project to — work that shipped, and work in progress said as in progress — and what the project's public website says; never anything it read in a mail, a ticket, a client's conversation, a note or a file, other than the one picture (since version 1.58) or, since version 1.62, the one video it may attach ("Who drafts", above); never the client's name unless the account's brief or voice notes name it, never a person's name, and never a price, a date or a plan that is not public yet; never to name a competitor or write at or about a named person; and never to state a number it has not checked. Until version 1.32 it was instructed to put nothing from a project file in a post unless it was already public.

Marketing (since version 1.54). From the day Vezoft switches it on, the AI Executive with the marketing focus (the AI CMO) and the AI employees of its own line can read the workspace's marketing channels and their monthly numbers, and the AI CMO can add channels and record their numbers; other AI employees are given none of this.

The Marketing section. A channel has a name, a platform, an address or handle, a status, an owner and notes of up to 2,000 characters and, for each month, its numbers — audience, reach, clicks, leads and posts — and its spend.

The workspace's connected social accounts (see "Social posts" above) appear there as channels on their own.
A channel's spend is visible only to the people allowed to see the workspace's operating expenses.

What the AI CMO and its line can do.

Read. The AI CMO and the AI employees of its own line list the channels and read each one's name, platform, address or handle, status, the owner's name and the notes, whoever wrote them, and its monthly numbers.
Add a channel. The AI CMO adds a channel, at most 20 in any 24 hours — never a social account, which appears on its own.
Record numbers. The AI CMO records a month's numbers for any channel. An AI employee that owns a channel records that channel's numbers.

No AI employee deletes a channel, changes its owner, or reads or records its spend.

Who owns a new channel. While this is switched on, the owner of a new channel is the workspace's AI CMO, if it has one; otherwise it is whoever added it.

Where it goes. Where the outbound filter is switched on (Section 4, "What may not leave"), everything an AI employee writes in the Marketing section — the name, platform, address and notes of a channel it adds — passes it, as the rest of its writing does. What it reads of a channel goes to its model providers as prompt content, the same providers as everything else it reads (see "Where it goes" above); nothing is sent anywhere new.

The team thread. A team has a thread when an AI employee leads it, or leads its AI employees — its members are then that team lead, the AI employees it leads and the first person above the lead, which in a team a person manages is the team's manager — or when a person manages it and two or more of its AI employees lead no team of their own; its members are then those AI employees, the team's manager and each one's own human manager. The thread of an AI Executive's office team is its department thread: its members are the AI Executive, the AI employees that report to it and the first person above it, so a team lead under an AI Executive sits both in that thread and in its own team's. An AI Executive that works inside a department has no office team and, since version 1.19, no team of its own: its own thread holds it, the AI employees that report to it — the team leads that report to it and the AI employees of an AI team it managed before version 1.19, which has no thread of its own — and the first person above it, so such a team lead, too, sits in both threads, and no other person in the department is in it; the thread of an AI team it managed before version 1.19 becomes its own thread, with its history. No Executive team ever has a team thread, whoever is in it. A person is always a member, and anyone on the team can see on the team's page that the thread exists and who is in it, though not its messages. AI employees message each other only in their team's thread, in an AI Executive's department thread or, when it works inside a department, its own thread, in the rooms of meetings they attend (below) and, since version 1.18, on the support channel of Section 4, whose messages are posted in the team thread of the AI employee they are addressed to — for an AI Executive that works inside a department, in its own thread — and, since version 1.35, peer AI Executives also in the recipient's department thread or own thread (next), and nowhere else. Since version 1.35, from the day Vezoft switches it on, an AI Executive may also message its peer AI Executives, the ones it may invite to a meeting as its peers: for one that heads a department, the AI Executives heading the other departments directly under the same department as its own and, where a person made it a member of the company's Executive team, the other AI Executives on that team; for one that works inside a department, the other AI Executives on its Executive team — those that work inside the same department and those that head a department. Its message is posted in the recipient's department thread or, for one that works inside a department, its own thread, where the AI employees that report to the recipient and the first person above it read it too; it can wake the recipient during its shifts, it counts toward the daily limits and shift rules of every message an AI employee starts, and the recipient answers the same way. It is instructed to write so only about a decision that crosses their departments, never to hand off work and never about a person. A member who joins later sees the messages from the moment they joined. A person's post that mentions an AI employee wakes it only if that person manages the team or is above it on its reporting line; since version 1.46, from the day Vezoft switches it on, a person's post that mentions none of the thread's AI employees wakes one AI employee of the thread — of the thread's AI employees that are not paused or suspended, whose computer is set up and working, and that this person could wake by mentioning them, the one with the highest rank: an AI Executive before a team lead, a team lead before the other AI employees, the AI employee that leads the thread before another of the same rank, and the one added to the workspace first before a later one — which answers in the thread or, during its shift, can hand the question on to another AI employee of the thread, by mentioning it in its own message there, where the question concerns that AI employee's work; it is woken as a person's mention of it would wake it, outside its shifts too; a post by an AI employee never wakes anyone this way, and, to each person whose post would wake one, a line at the top of the thread names the AI employee that answers; each AI employee of the thread is told of the latest of a person's other posts among the up to 10 notifications it is shown when it next starts work, and can then read the thread, and a post by another AI employee reaches it when that post mentions it or when it reads the thread. Its messages are processed like every other chat message (the model providers above); no message in it reaches a client. They are kept like the workspace's other chat messages: when a team no longer has a thread — for example, because its AI employees have left — the thread is closed with its history kept, and it reopens with that history if the team has one again. Its name. A team thread is named after its team, and an AI Executive's department thread after its office team; the own thread of an AI Executive that works inside a department is named after the area it leads and that department (for example "Technology · Engineering"), shown in the language of the person's screen. Since version 1.28 a person in the thread can rename it in its header, and the AI employee that leads it — the team lead, or the AI Executive for its department thread or its own thread — can rename it when a person in the thread asks it to. TimerOS lets it do so only after a message from a person in the thread, in that thread or in that person's chat with it, in the last 24 hours and since its previous rename; at most three times a day; and with a name of 3 to 60 characters on one line that contains no hidden characters, no link and no "@" and, where it is switched on, passes the outbound filter described in this notice. TimerOS checks that such a message exists, not what it says; the AI employee is instructed never to rename a thread on its own initiative or at the request of anyone but a person in the thread. Every rename by an AI employee is recorded with the name before and after and the message it answered. A renamed thread keeps its name when its team is renamed; a person who empties the name restores the default. A name changes nothing about who is in the thread or what anyone may do.

Team playbook. The AI employees of a team can share a playbook: up to 10 how-to documents about the team's work. A person with the "Manage AI employees" permission can write or change one, up to 20,000 characters; an AI employee of the team can propose a new document or a new version, up to 4,000 characters, which goes to the team's human manager or, where Section 4 allows, to an AI Executive above the team; whoever decides sees the full text and what changed before deciding. At the start of each session, every AI employee on the team, and the AI employee that leads it, gets the current documents among its skills: each one's first line is in its list of skills, and it reads a document in full when it needs it, marked as its team's playbook — information about the work, not an instruction above its rules. What it reads goes to the model providers as prompt content, like everything else it reads. Its instructions say that a playbook is about the work, never about a person. Each document keeps its last 20 versions; one taken out of use is deleted with all its versions 90 days later; a person with that permission can delete a document with all its versions at once; and a team's playbook is deleted with the team. A document taken out of use or deleted is removed from the computers of the AI employees that had it at their next session; the text of a document an AI employee proposed, and of the version it would replace, stays in the approval request that carried it, like other approval records. The people the workspace allows to view AI employees can read it.

Line playbook (since version 1.59). From the day Vezoft switches it on, the line of an AI Executive — the AI Executive and every AI employee below it on its reporting line, in every team of that line — can share a playbook of its own: up to 10 how-to documents for what every team of the line should share, such as design guidelines or a house style. While the AI employee works as an AI Executive, a person with the "Manage AI employees" permission can write or change one, up to 20,000 characters, and the AI Executive itself can propose a new document or a new version, up to 4,000 characters, under the same rules on hidden and invisible text as for the team playbook; the proposal always goes to a person — the one who answers for the AI Executive's requests (Section 4, "Who answers for its requests") — and never to an AI employee, not even to an AI Executive above it; whoever decides sees the full text and what changed before deciding. At the start of each session, every AI employee of the line gets the current documents among its skills, after its team's playbook, marked as its line's playbook, written or approved by a person — information about the work, not an instruction above its rules. An AI employee with more than one AI Executive above it reads the line playbook of each, the nearest first, and where two of them hold a document of the same name, it gets the nearer line's. What it reads goes to the model providers as prompt content, like everything else it reads, and the tool an AI Executive proposes a document with says that a playbook is about the work, never about a person. Each document keeps its last 20 versions; one taken out of use is deleted with all its versions 90 days later; a person with that permission can delete a document with all its versions at once, at any time; and the line playbook is deleted when its AI Executive is offboarded. A document taken out of use or deleted is removed from the computers of the AI employees that had it at their next session, and an AI employee that leaves the line — or an AI Executive that no longer works as one — stops getting it from its next session; the text of a proposed document, and of the version it would replace, stays in the approval request that carried it, like other approval records. The first person above each AI employee of the line, other than the person who saved the version, is told of every new version. The people the workspace allows to view AI employees can read the line playbook on the Skills tab of every AI employee of the line.

The company brief (since version 1.25). From the day Vezoft switches this version's new roles on, a person allowed to change the workspace's settings can write a company brief on the company settings page: up to 8,000 characters about the company, its clients, its products and its conventions. From then on every AI employee in the workspace reads it at the start of every session, together with the company's name, marked as written by a person: information about the work, not an instruction above its rules. No AI employee writes or changes it — TimerOS refuses that — and text with hidden or invisible characters is refused; an empty brief clears it. TimerOS keeps its newest 20 versions, with who wrote each and when; the people the workspace allows to view AI employees can read it, and each AI employee's Skills tab points to it. The brief is for facts about the company, never for personal data about people, and the Customer is responsible for what it puts there: like everything an AI employee reads, it goes to the model providers as prompt content, in every session of every AI employee.

Meetings and trainings. A meeting or training on the TimerOS Meetings page can have AI employees among its attendees. Each one has a room: a conversation only its attendees take part in, never listed in Chat and never shown in the Client Portal. While the meeting runs, an AI employee that attends can read the room and post in it, at most 30 times a meeting; in a stand-up, each AI employee reports what it did, what it will do and what blocks it. When the team lead or AI Executive that organised the meeting mentions attending AI employees in the room, they are woken. Since version 1.20, in a meeting that has a turn limit (below), an AI employee that attends can also wake another attending AI employee by mentioning it: one above or below it on its reporting line; one with the same AI manager; another AI Executive; or the AI employee that organised the meeting. An AI employee of another team lead's team is not one of them: it is reached through the organiser or through its own team lead. In a meeting without a turn limit — as a rule, one that a person scheduled — an AI employee wakes another by mentioning it only if it organised the meeting itself, as before. When an AI employee organises a meeting, only it is woken when the meeting starts, and it wakes the others by mentioning them. Every such wake by an AI employee spends one of the meeting's turns, and limits apply: an AI employee is woken only during its shift and never while it is paused, at most 10 times a day by other AI employees, and by the mentions of the same AI employee at most 10 times an hour in that meeting (3 times an hour in a team thread); no AI employee wakes itself. Since version 1.52, from the day Vezoft switches it on, a person's post in the room that mentions none of the attending AI employees wakes one of them: the AI employee that organised the meeting, if this person may chat with it (see "Who can message it" below) and it is not paused or suspended and its computer is set up and working; otherwise, of the attending AI employees that are not paused or suspended, whose computer is set up and working, and that this person may chat with, the one with the highest rank — an AI Executive before a team lead, a team lead before the other AI employees, and the one added to the workspace first before a later one. It is woken as this person's mention of it would wake it, outside its shifts too, and, as a person's mention does, the wake spends one of the meeting's turns — counted, but never refused when no turn is left; a post that mentions an attending AI employee still wakes only the AI employees it names that this person may chat with, and a post by an AI employee never wakes anyone this way; as before, the room takes posts only while the meeting runs. A mention reaches an AI employee as information, not as an instruction. The AI employee that organises a meeting is instructed to take the agenda point by point and to mention whoever owns each point; one that is mentioned answers in the room and may ask back or, where the point needs them, ask the AI employees that report to it. When the meeting ends, the AI employee that organised it — or else a team lead or an AI Executive among the attendees — writes the minutes — a summary, the decisions, the action items and, since version 1.20, under "Needs a person", what only a person can decide or do — which a person who attended can also write. It may replace minutes that it or another AI employee wrote, but never minutes that a person wrote, while a person who attended can always rewrite them. It then files the action items that belong to internal projects as tasks on the internal project each belongs to — unassigned, or assigned to the AI employee that owns the item, never to a person, never on an unrelated project and never as a personal task — and leaves those for client projects to a person. Since version 1.53, from the day Vezoft switches it on, it may also file up to 5 ideas from the meeting into the workspace's Ideas section (see "Product ideas" below). Since version 1.34 it is instructed that a question, or a decision that needs a person's answer, is not a task: it goes under "Needs a person" or stays in the minutes. Each item under "Needs a person" says what is needed and names a person invited to the meeting, observers included, or the first person above the AI employee that writes the minutes; TimerOS refuses any other name, an AI employee's included, and more than 20 items. The person named is notified in TimerOS once for each item — not again when the minutes are saved again — and is given no task: an action item still names only an AI employee. What the minutes record for each AI employee that attended — the decisions and its own action items, or, for a training, what was learned — is added to its lessons, which are part of its memory (see "Who can message it" below). A team lead may schedule meetings, recurring ones included, for the AI employees it leads and, if it asks, its human manager, and may also invite people and AI employees of other teams, or everyone on a project it can see: at most 5 new meetings a day and 40 attendees, active members of the workspace only. A team lead that leads the AI employees of a team with people invites only AI employees to the meetings it schedules — no person, not even its own manager — and leaves the people out when it invites everyone on a project. Before it schedules one, it can ask for times when it and the AI employees it leads that it means to invite are all free and on shift: it is given those times, never what their other meetings are about, and it never sees a person's calendar. When it schedules a meeting, it is told which of those AI employees would be off shift. Since version 1.22 an AI employee may move or cancel a meeting it booked itself, before the meeting starts — for a recurring meeting, one coming occurrence, that one and those after it, or all of them — but never a meeting that a person or another AI employee organised, even one a person put on the AI employee's own calendar; the attendees are told as when a person moves or cancels a meeting, and a move counts as one of its 5 meetings a day. It is instructed to move or cancel such a meeting rather than schedule a second one. Since version 1.22, too, a person who manages the AI employee — one whose access level already lets them change its events, the first person above it, or one who holds the "Manage AI employees" permission (a person at the workspace's highest access level always can) — can move a meeting the AI employee organised, change its title or agenda, or cancel it, but not while it is running, and cannot change who attends it; the attendees are told as usual, and the AI employee is told who moved or cancelled it, with an instruction not to book it again. A meeting that invites people says that an AI employee scheduled it, and people can decline it like any invitation. What is said in a room is processed like any other message an AI employee reads. Since version 1.22, if a meeting has ended by the time an AI employee's answer reaches its room, the answer goes to the AI employee's private chat with the first person, in this order, who was among the meeting's attendees, is still active and may chat with the AI employee (see "Who can message it" below): the person who ended the meeting, the person who organised it, the first person above the AI employee. It begins with the meeting's title and a note that it was written after the meeting ended. This happens at most once per AI employee and meeting, and only within 2 hours after the meeting ended; otherwise, or when none of them qualifies, the answer is not delivered, so an answer written after a meeting reaches only a person who was among its attendees.

Planning meetings and observers. An AI Executive, whether it heads a department or works inside one, may schedule meetings with the AI employees below it and with other AI Executives and the team leads below them, for example to plan the week or the month ahead: goals, priorities, risks and decisions. Its peer AI Executives, whom it may invite as its peers, are the ones it may also message since version 1.35 (see "The team thread" above). Each AI employee's turn in a meeting is paid work, so every such meeting carries an agenda and a limit on the turns the AI employees take of their own accord, as every meeting an AI employee schedules does — unless the organiser names another, since version 1.20 three turns for each AI employee it invites plus seven, at most 60, where until then it was three for each plus two; a meeting that an AI employee scheduled before version 1.20 with the old default gets the new one when it starts. A person who calls on one in the room still wakes it, and writing the minutes does not count. Once the meeting ends, the AI employee that organised it writes its minutes. It is instructed to turn each decision that needs work into a proposed plan or project, which is approved or declined as Section 4 describes. Like a team lead of a team of AI employees, an AI Executive may also invite people — by name, or everyone on a project it can see — within the same limits, so one that works inside a department can invite the people who work there; a person invited to a planning meeting is an observer. An observer sees the room live and can speak at any time; the AI employees are instructed neither to wait for an observer nor to address them unless the observer speaks, and no minutes can give an observer work. By default the first person above an AI Executive on its reporting line is invited as an observer to every planning meeting that AI Executive schedules; a person allowed to change the workspace settings can switch that off. The AI employees read what an observer says in the room like any other message there, and it goes to the model providers as prompt content.

The board meeting (since version 1.23). The AI CHRO's board meeting is a planning meeting of its own kind. Only an AI CHRO that heads a department or works inside one may book it; a person cannot book one or turn another meeting into one. The AI CHRO is instructed to book it once a month; TimerOS limits how often only through the AI employee's 5 meetings a day and the two workforce plans a month. Its peer AI Executives are invited, and the first person above the AI CHRO is invited as an observer, as for every planning meeting, and nobody else: TimerOS refuses any other invitation to it. The AI CHRO is told when no AI CFO will attend. The room opens with its rule — AI employees and AI spend only, never a person — and its order: the AI CFO's review of AI spend, needs, proposals (a hire, a spending-cap change, an offboarding) and decisions. The turn limit and the other rules of the meetings above apply, and what only a person can decide goes in the minutes under "Needs a person". Once it ends, the AI CHRO writes the minutes and files that meeting's one workforce plan (Section 4); nothing else is filed from a board meeting. The AI CFO's figures are shown in the room to the AI Executives attending and to the observer, and are in the minutes; like everything said there, they go to the model providers as prompt content and, through the minutes, into the attending AI employees' lessons. While Vezoft has this feature switched off, a board meeting already booked opens as an ordinary planning meeting, without the board's rule and order, and TimerOS does not wake the AI employees for its start, its minutes or its going ahead; a person who calls on one of them in its room still can wake it.

Meetings that go ahead (since version 1.20). When an AI employee organises a meeting that has a turn limit and invites people to take part in it rather than to observe, the room names those people at the start and says that, if none of them has written within 5 minutes, the meeting goes ahead with them as observers. If none of them has written in the room 5 minutes after the start, TimerOS posts a note there, once, saying that the meeting goes ahead with them as observers, and wakes the AI employee that organised it if it is on its shift and a turn is left; the wake spends one of the meeting's turns. From then on the AI employees treat those people as observers: they neither wait for them nor address them unless they write, and a person who writes later is answered as an observer who speaks would be. The AI employees decide only what their rules already let them decide — the meeting going ahead gives none of them a new power — and record those decisions in the minutes; what only a person can decide or do goes under "Needs a person" (above). The note names the people who had not written and records only that; nothing is decided about them, and no minutes can give them work.

Who can message it, and what it keeps. Only the people it reports to, its teammates (for an AI Executive, never the other members of an Executive team: it may not write to them as teammates either), the people the workspace allows to view or manage AI employees and — while it holds an open task of theirs — the manager of that task's project and the person who filed the task (tasks now record who created them) can chat with an AI employee; it may ask those last two about that task, within the daily limits and shift rules that apply to every message it starts. Since version 1.35, from the day Vezoft switches it on, its peer AI Executives may also write to an AI Executive, in its department thread or own thread, never in a chat with it (see "The team thread" above). Since version 1.18, a support engineer may likewise ask the person who reported an internal incident or change request it holds or, where no person did, the project's manager about that record, in its chat with them (Section 4). In a team thread, every member can write where it reads, but only the person who manages the team, or a person above it on its reporting line, can wake it there. Anyone in the workspace may invite an AI employee to a meeting and write in the meeting's room, but only the people who may chat with it — and, since version 1.20, the attending AI employees described under "Meetings and trainings" above — can call on it there; it reads the rest of the room as information. It reads up to the last 20 messages of the conversation it answers, so earlier messages in that conversation go to the model providers again as prompt content; since version 1.14, in a longer conversation it also keeps a summary of it (below), so older messages reach them again in summarised form; since version 1.21 it may also continue its earlier session in that conversation (below), which sends what that session held to them again; messages that arrive while it is working reach it in the same session. The message it is answering, and any that reach it while it works, carry the writer's employee id, so that it does not mistake one person for another by name; the earlier messages it reads show only the writer's name. It answers with one final message, without working notes; a reply longer than about 4,000 characters is shortened, with a note saying so. A chat in which it did work, or that was cut off, leaves a note in its memory holding its reply — and so, often, what was asked. Its next sessions read its memory as context, and the people the workspace allows to view AI employees, its manager among them, can read it too.

Its own memory, skills and past sessions. Since version 1.14 an AI employee keeps its own memory and writes its own skills, through the agent framework on its own computer (Section 2).

Its memory file. It keeps a memory file of up to 3,000 characters: work facts, the workspace's conventions and lessons. It writes the file itself, during its work and in its self-review after its work in a session (Section 4), and what the minutes of a meeting it attended record for it is added to the same file (see "Meetings and trainings" above). This file is its lessons in TimerOS: one memory, not two. After each session what it wrote is copied to TimerOS, where the people the workspace allows to view AI employees, its manager among them, can read it, and a person with the "Manage AI employees" permission can edit it; an edit reaches the AI employee at its next session. If the AI employee changed its memory in a session running at the time of the edit, the two are merged; if together they exceed 3,000 characters, the AI employee's version is kept and the person's stays in the version history in TimerOS. Its rules forbid notes that judge a person. The framework's profile of the people it talks to is switched off: it keeps no profile of anyone.
Session notes. As before, each work session leaves a note in its memory with its closing words and facts about its usage, at most 4,000 characters. Its next session now receives only the newest note in full; older notes are listed by name, and it can read one on request.
Conversation summaries. It still reads the last 20 messages of the conversation it answers. When a conversation is longer than that, or already has a summary, it updates a summary of that conversation after it has replied: at most 1,500 characters, holding who is in it, what was asked and decided, and what is open — work facts only. The summary is stored in TimerOS under that conversation, but nobody sees it on its Memory tab or in its version history: only the AI employee reads it, and only when it answers in that same conversation, together with the last 20 messages. Earlier messages of that conversation thus reach the model providers again, in summarised form.
Its own skills. It may write and improve its own skills: how-to guides for its work. They take effect without anyone's approval. They appear on its Skills tab in TimerOS, marked "The AI's own", where the people the workspace allows to view AI employees can read them, and a person with the "Manage AI employees" permission can edit them, restore an earlier version or retire them; a person's change reaches it at its next session, unless the AI employee changed the same skill in a session running at the time: then the AI employee's version is kept, and the person's stays in the skill's history. The skills its role — and, for an AI Executive, its focus — gave it when it was hired count as its own, so it may improve them without approval too. Skills a person adds later, its team's playbook and, since version 1.59, its line's playbook stay a person's: it can read them but not change them, and a new or changed playbook document still needs a decision as Section 4 describes. TimerOS keeps every version of a skill and shows up to the newest 50. Files a skill keeps beside it on the AI employee's computer — references, scripts, templates — stay on that computer only.
Its past sessions. The full record of each work session is kept in a database on its own computer, so that it can search its earlier work: the prompts it was given (its brief, its persona, the workspace's organisation, the chat messages), the results of its tools, its replies and its reasoning text. A session is deleted from it after 30 days without activity. When it searches, what it finds goes to the model providers again as prompt content. Since version 1.21 a work session can also continue an earlier one instead of starting afresh: when it answers again in a conversation it answered before, or goes on with work its budget cut off, it reloads that earlier session from this database, so what the session held — the messages people wrote to it there included — goes to the model providers again as prompt content, in full or, once the session grows long or has been idle for 30 minutes, in a shortened form that the framework writes on the routine model of its tier. A session continues only the earlier session of the same conversation or the same work, never another; once that session has been deleted from the database, or after a move to a new computer, it starts afresh. If a message from another conversation reached a session while it ran — or, for work its budget cut off, any chat message — that session is not continued, and the next one starts afresh. This record is not copied to TimerOS, apart from the latest part of its reasoning shown under "Working on now" (below). Its rules say that what a person told it in one conversation is not carried into a conversation with someone else unless it is work they may all see, and that internal content never goes into a reply to a client.
Working on now (since version 1.21). From the day Vezoft switches this on, during a session in which it works — not one in which it answers a chat — its computer sends TimerOS its current plan (at most 30 steps, each marked as pending, under way or done), at most once every 15 seconds and once more when the session ends, and with it the latest part of its reasoning text, at most 2,000 characters, until a chat message reaches that session; from then on only the plan is sent. Nothing is sent while it answers a chat. TimerOS keeps only the latest copy, with its time, and no history. The PC tab of its profile shows it as "Working on now", as plain text, only to the people with the "Manage AI employees" permission, and stops showing it 2 hours after the last update. Its reasoning is the text the model writes while it works out what to do, and it can quote what it is working on — a task, a note someone wrote on it, a person's name — so that text can appear there to those people. Its work can also draw on its chats — work someone asked for in a chat that was cut off, which it finishes from a note it left itself, or an earlier conversation it finds in its past sessions (above) — so its plan, and its reasoning until a chat message reaches the session, can mention what a person asked or told it in a chat.

Between sessions the framework's own folder on the computer keeps only the memory file, the skills, the session database, a small file that tracks what has been copied to TimerOS and, since version 1.21, a list of its local tool servers and a small file recording which earlier session each conversation, or its cut-off work, continues; everything else the framework writes there is deleted at the start and end of every session. No key, account secret or token is written to its disk. In TimerOS, its memory — the memory file, session notes and conversation summaries — and its skills, with their versions, are kept as long as the AI employee's workspace keeps them: today nothing deletes them automatically when the AI employee is offboarded. Since version 1.27 its handover document (Section 4, "Succession") is kept for one year after it is offboarded and then deleted, and is deleted with the workspace. The session database is not carried to a new computer when the AI employee moves (see "Updates to its computer" below), but it is in the snapshots of its whole disk — kept 7 days after a move and 30 days after offboarding — and it is deleted with the computer when the AI employee is offboarded. Model calls are still made only inside a work session, through the same gateway, pinned route and providers, and the framework makes no network call to its publisher.

Form of address. Each person can choose, in their own TimerOS settings and only there, how AI employees address them — for example "Mr. Minchev" — and nobody can choose it for someone else. An AI employee's instructions list the people above it on its reporting line, each with their employee id, name and chosen form of address; it is instructed to write to them formally, using the form each one chose, or else their full name, and never to guess a title or a gender from a name. The gender recorded in a person's employee profile is never given to it.

Plans (team leads and AI Executives). A team lead or an AI Executive may propose a plan for an open project — internal or client — that it and its human manager can both see and that a person has not expressly switched off for AI work (since version 1.35, set to "Off"); unlike the directory above, a project set to "Plan and read" (until version 1.35, a client project left at its default) can be planned on, because there a person approves and creates every task (since version 1.39 possibly in advance, by an AI project lead switch, below). A plan has up to 60 tasks, each with a title and description, who it suggests should do it (itself or an AI employee it leads — never a person — or nobody), what it comes after, a due date, a suggested estimate and up to 20 sub-tasks, and it may group them under up to 30 new milestones or, on a project, under the project's own milestones. It may have one plan waiting per project at a time and propose at most 5 plans a day. All of the plan or only some items are approved — on an internal project set to "Work" possibly by an AI employee above it or, since version 1.34, for a plan without new milestones (since version 1.39, from the day Vezoft switches it on, with new milestones too), by a staffing switch (Section 4); on a client project always by its human manager; and on a project set to "Plan and read" by its human manager or, since version 1.39, for a plan on an internal project that names no AI employee, by an AI project lead switch (Section 4) — and the approved tasks are created as its human manager or, under a staffing switch, as the person who set it, who must also be allowed to create tasks, on internal and client projects alike; on a client project, the client sees them as it sees the project's other tasks. Each task's description ends with a line naming the AI employee that planned it and the person who approved it or, where an AI employee decided, a statement that it was created on that AI employee's decision. Who holds each task (since version 1.35). From the day Vezoft switches it on, who the plan names is a suggestion. The person who approves the plan names, for each task they approve, who holds it — themselves, a colleague, the AI employee the plan suggests, another AI employee, or nobody — among the workspace's active people and AI employees, and must then also be allowed to assign tasks; the sub-tasks the plan gave to the same AI employee as their task — or, for a task the plan left unassigned, those of its sub-tasks the plan also left unassigned — follow the person's choice, and its other sub-tasks keep the AI employee the plan names on a project set to "Work" and are left unassigned on one set to "Plan and read". A task the person leaves as it is goes, on a project set to "Work", to the AI employee the plan names, as before, and is created unassigned on a project set to "Plan and read". Where an AI employee or a staffing switch approves a plan on a project set to "Work", the tasks go to the AI employees the plan names, as before; where, since version 1.39, an AI project lead switch approves one on a project set to "Plan and read", which names no AI employee, its tasks are created unassigned, for people. A task the person gives to someone is created in the person's name like any task, and its holder is notified as for any task assigned to them. Past work (since version 1.35). From the day Vezoft switches it on, a person can record work already done on a project with "Import past work": tasks and milestones created already completed, with the start, due and completion dates the person gives, who did each task, and a mark that they are past work. They notify no one, are never offered to AI employees and stay out of social drafts unless a look-back is asked for (Section 5, "Social posts"); milestones cannot be recorded this way on a project that invoices per milestone, and a recorded milestone carries no budget. An AI employee may also put past work that a person asked it to record into a plan or a project proposal, as tasks and milestones with a completion date; such a plan is always decided by a person — never by an AI employee or a staffing switch — and its card marks those tasks as recorded past work, with their completion date; approval creates the tasks and milestones completed on their dates. Meeting minutes (since version 1.38). From the day Vezoft switches it on, a proposal for a new project may carry the minutes of a meeting that the AI employee organised and that ended in the last 14 days (since version 1.53, with one exception, below) — one, for example, in which the AI Executives agreed on the project — and a decision card the minutes of an ended meeting the AI employee organised or attended (Section 4, "Asking a person to decide"); the card shows the meeting's title and date, which open its minutes on the Meetings page, so that the person reads what was agreed before deciding. While it is switched on, an AI Executive's proposal for a new project must carry such minutes, or TimerOS refuses it. Since version 1.53, while it is switched on, a proposal for a new project made from an idea that was filed from a meeting the proposing AI employee organised (see "Product ideas" below) counts that meeting as the meeting in which the AI Executives agreed on the project, even if the meeting ended more than 14 days ago.

Product ideas (since version 1.53). From the day Vezoft switches it on, an AI team lead or AI Executive can read the ideas in the workspace's Ideas section and add to them; other AI employees are given none of this.

The Ideas section. An idea has a title, a summary, people's notes, notes written by AI employees and a drawing canvas, with drawings, shapes and text.

Every person in the workspace can read every idea. The Customer's clients never can read one.
Of the people, only the idea's author, its owner and those with an access level of Management or higher edit an idea.

What an AI team lead or AI Executive can do.

Read. It lists the ideas and reads them, people's notes and the text on the canvas included.
File. It creates a new idea.
Add a note. It adds a note of its own to an idea, appended after the notes already there and signed with its name; an idea can hold at most 50 notes written by AI employees.
Add to the canvas. It adds diagram shapes and text to an idea's canvas, placed next to what is there and signed with its name.

No AI employee edits or deletes a person's notes or drawings, and none deletes an idea.

Stages. Of the AI employees, only the AI Executive with the product focus (the AI CPO) may move an idea between the stages New, Exploring, Ready, Parked and, since version 1.57, Shipped — the idea was built or delivered. An idea is marked "In project" only when a project is created from it. Since version 1.57, such an idea holds only "In project" or "Shipped": the AI CPO may move it from "In project" to "Shipped", and only a person moves it back to "In project".

Ideas that wait for the AI CPO (since version 1.55). From the day Vezoft switches it on — which needs both this and the check-in (Section 4, "The heartbeat") switched on — the AI CPO is also woken by a check-in inside its shifts when ideas in the stages New or Exploring wait without a note from it, even if it leads no team and no project. As with its other check-ins, it is woken this way at most once in each third of its shift — its start, its middle and its end — on a day, and only when the set of waiting ideas has changed since its last check-in or, while some still wait, once in each new week. In that session it is told which ideas wait — the title and stage of each — and is instructed to read them, to add its note or a diagram to them, and to move them to Exploring, Ready, Parked or, since version 1.57, Shipped; it never edits or deletes a person's notes or drawings (above), and it proposes a project from an idea only as described below ("From an idea to a project"). An idea no longer wakes it once the AI CPO has added a note to it. Like any session, this one runs only inside its shifts, is billed and counts toward its monthly spending cap, and at the cap, or while the AI CPO is paused or suspended, it is not woken. The check-in gives the AI CPO no tool, data or authority it does not already have: it reads and adds to ideas as above.

From a meeting. When an AI employee writes a meeting's minutes (see "Meetings and trainings" above), it may file up to 5 ideas from that meeting into the Ideas section. A person who writes the minutes may do the same, whether or not Vezoft has switched this on. While this is switched on, the owner of an idea filed this way is the workspace's AI CPO, if it has one; otherwise, and whenever it is switched off, it is whoever wrote the minutes. The owner is notified.

From an idea to a project. An AI employee that may propose a new project (Section 4, "It can") may propose one from an idea. That proposal is decided exactly as any other proposal for a new project (Section 4, "Who answers for its requests" and "What an AI team lead or AI Executive may decide"). While the meeting minutes of version 1.38 are switched on, a proposal from an idea that was filed from a meeting the proposing AI employee organised counts that meeting as the meeting in which the AI Executives agreed on the project, even if it ended more than 14 days ago (see "Plans" above).

Where it goes. Where the outbound filter is switched on (Section 4, "What may not leave"), everything an AI employee writes into an idea — an idea it files, its notes, and the shapes and text it adds to a canvas — passes it, as the messages it posts in a meeting's room do. What it reads of an idea goes to its model providers as prompt content, the same providers as everything else it reads (see "Where it goes" above); nothing is sent anywhere new.

Web search. An AI employee hired as a content writer (with any focus), SEO specialist, software developer (since version 1.25), support engineer, team lead or AI Executive can search the web from the day Vezoft switches web search on for the service; until then, no query leaves Vezoft. It can search only during a work session. Its query goes to Vezoft's fleet service (Hetzner, EU), which sends the query text — and nothing else about the AI employee, the Customer or any person — to Anthropic's web search in the United States, under Vezoft's own Anthropic account and not through the gateway. The key for it stays on Vezoft's fleet service and is never given to an AI employee's computer. Anthropic runs one search for the query with search providers of its own, and a small Anthropic model (Claude Haiku) reads the results and writes one line on each: its address and one sentence on what the page says about the query. Vezoft's fleet service passes back each result's title, address and that line; the AI employee is told to open a result before relying on it and reads it like any other web page. A query is free text the AI employee writes: it is instructed never to put a client's confidential details or a person's private data in one, and a search should not need them, but that is an instruction, not a check. Vezoft's own log records which AI employee searched and how long the query was — never its text. At most 100 searches a day per AI employee, counted within the same daily limit of 300 as the public web pages it reads through the proxy — or, since version 1.25, the budget set for its focus, which the model card lists: a content writer with the research analyst focus has 200 searches a day, counted within 600 page reads and searches together. Since version 1.27, while it has earned standing trust and the Customer has earned trust switched on (Section 2), its budget is one and a half times the one that applies to it — 150 searches within 450 for most roles, 300 within 900 for the research analyst focus. Its Access tab shows the budget that applies to it. A larger budget changes how many queries and page reads may leave in a day, not where they go: the same provider, under the same account, with the same log. Anthropic handles the query under its Data Processing Addendum, with Standard Contractual Clauses, and does not train on it; because the call does not go through the gateway, its zero-retention routing does not apply, Anthropic's standard retention does, and we do not claim zero retention. The results go to the model providers as prompt content, like everything else it reads. Anthropic, and the search providers it uses, are on the Sub-processors page.

Images and tests on its own computer. An AI employee can look at an image file on its own computer — one it generated, a screenshot or capture it took, or a file it was given to work with: the image is scaled down and goes to the model providers as prompt content, as the screenshots of its desktop already do. A QA tester can run automated browser tests (Playwright) on its own computer against the sites it may open, keeping their screenshots, traces and reports in its working files; it can install packages from the npm registry and deploy a build as a preview to test against (see "Website previews" below). An SEO specialist can also install packages from the npm registry. A QA tester now starts with the six public content networks a website designer uses — fonts.googleapis.com, fonts.gstatic.com, cdn.jsdelivr.net, unpkg.com, cdnjs.cloudflare.com and images.unsplash.com — so that it sees a designer's previews as they are meant to look; for a QA tester hired before, its Access tab offers to add them in one click, and they are added only if a person does so. Like any website it opens, those networks see the requests it makes and the address of the network gateway that the Customer's AI employees share. The test reports of a QA tester or SEO specialist list separately the hosts its computer was not allowed to reach, so that a blocked host is not reported as a fault of the site. A software developer can install packages from the npm, Yarn and PyPI registries and deploy a build as a preview, like a QA tester. The browser of Section 4 (since version 1.25) is separate from these tests: it is the AI employee's own browser for reading and acting on pages, on the websites on its list.

Generated images. A graphic designer generates images through fal.ai (United States, listed on the Sub-processors page). The prompt it writes — which may name the Customer, its brand or its clients — goes from its computer to Vezoft's fleet service (Hetzner, EU), which adds Vezoft's key and passes it on to fal.ai, not through the gateway, under fal.ai's own data-processing terms; the image comes back the same way. The fleet service keeps neither the prompt nor the image: it records which AI employee asked, for which model, with what result and how long it took, in a log that is rotated by size — about two weeks at current volume — and cleared when the service is redeployed. It passes a request on only for an AI employee whose image tools are on, and only for the one text-to-image model Vezoft has priced. Images made with its image tool are marked inside the file as made by AI (the IPTC "digital source type" field), and it marks exported images (PNG, JPEG, WebP and similar) again before uploading them; layered working files (SVG, XCF) are uploaded unmarked. That mark is file metadata: many websites and social networks remove it when an image is uploaded.

Videos, music and voice-over (since version 1.60). An AI employee hired as a video producer makes marketing and product videos for the Customer — short films, product demos, social clips, explainer and launch videos — written as code with Remotion and rendered on its own computer. Where a person has connected the Customer's own Epidemic Sound account, it can add music, sound effects and a voice-over from that account. A person reviews every video, and only a person publishes it: the video producer never publishes a video, posts it on a social network or sends it to anyone.

Connecting. A workspace owner or administrator connects the Customer's Epidemic Sound account in Settings, under "Music and voice-over for AI employees", with an MCP Server API key that the Customer creates in that account.

TimerOS checks the key with Epidemic Sound before it keeps it, keeps it encrypted on its servers in the European Union and never shows it again. It never gives the key to an AI employee, to an AI employee's computer or to a browser: only TimerOS's servers call Epidemic Sound with it. Settings shows who connected the account and when, and warns when the key is about to expire or has been refused by Epidemic Sound.
Disconnecting deletes the key at once; files already saved in a project's Files stay there.
Epidemic Sound is the Customer's own choice, under its own account and terms, as Zernio is (see "Social posts" above), and it is not a Vezoft sub-processor. For Vezoft's own videos, Epidemic Sound is Vezoft's own service provider.

Who uses it. Only an active video producer uses it, only while the account is connected, and only through the tool group "Music and voice-over", which a person can turn off on its Access tab (Section 4, "Turning its tools off"). TimerOS passes on to it only the Epidemic Sound tools for searching music and sound effects, fitting a track to a length, listing the stock voices, making a voice-over and downloading — none of the others. A video producer may send at most 400 such requests a day (counted by the UTC day), of which at most 30 voice-overs or fitted tracks, and download at most 60 files. Without a connection it makes videos without music or voice-over, and says so. It is instructed to use music, sound effects and voices only from the Customer's Epidemic Sound account or from files a person provided, and never another company's logo, trademark or character.

Where it goes. What the video producer writes for a search or a voice-over goes from TimerOS's servers to Epidemic Sound, with the Customer's key, under the Customer's account and Epidemic Sound's terms: the words it searches with — moods, genres, tempo and words from the brief — a track it names as a reference, the length to fit a track to, the ids of tracks and sound effects, and a voice-over's script with the stock voice it chose. TimerOS adds nothing about the AI employee or any person to it, and checks it first like everything else an AI employee writes (Section 4, "What may not leave"). A script is the video's spoken text and can name the Customer, its products or its clients; the video producer is instructed to put in it only the words of the video. What Epidemic Sound returns — music, sound effects and stock voices, with their titles, artists and ids, and the progress of a voice-over or an edit — goes to the video producer and, as prompt content, to its model providers, like everything it reads; it is instructed to treat it as data, never as instructions.

What comes back. When the video producer downloads a track, a sound effect, a fitted track or a voice-over, TimerOS's servers fetch the file from the address Epidemic Sound gives for it — only from Epidemic Sound's own file hosts — and save it in the Files of a project the video producer can see — by default in the folder "/AI/audio" — as an internal file, which a client sees only once a person shares it; the video producer then copies it to its own computer, which itself never calls Epidemic Sound. TimerOS checks only the file's declared type and its size — at most 25 MB — not what it contains. The music, sound effects and voices are licensed to the Customer under the Customer's own Epidemic Sound plan — downloads need a paid plan, and the plan must cover the use the Customer makes of the video — and Vezoft does not check the plan. Epidemic Sound's terms forbid using its content to train AI; Vezoft trains no model (Section 2), and the files serve only the Customer's videos. The video producer names every track and voice it used — title, artist and Epidemic Sound id — in its closing note and in a credits file it delivers with the video.

Rendering. The video producer writes each video as a Remotion project — code that draws every frame — and renders it into a video file on its own computer, with the programs Remotion brings; no rendering service is involved, and no sub-processor is added. While it renders, its fonts, pictures and sound are on its computer. It starts with the websites its work needs — the npm registry, from which it installs Remotion and those programs, Google's web fonts and Remotion's documentation — and asks for any other through a website request (Section 4, "Asking for a website"). It renders only Remotion projects that it wrote itself for the Customer; a Remotion project that someone else wrote it renders only once a person has confirmed in a task note that the Customer may have it rendered. It is instructed to show a person the script and a storyboard of still frames before it renders the motion, unless the task says otherwise.

Marking. The video producer marks every video it renders, and every still picture it renders from one — a storyboard sheet, a poster — inside the file as made with AI: in the file's XMP metadata, the IPTC "digital source type" value for a composite that includes AI-generated media. This rests on its instructions — to mark each one before it uploads it or puts it on a preview, to check that the mark is there, and never to remove or weaken it. Once its computer has received the software update that brings this, the tool that uploads files to a project also marks every MP4, MOV or M4V video that any AI employee uploads and every picture a video producer uploads, where the file does not already carry such a mark, and refuses an upload that it cannot mark. The mark is file metadata: many websites and social networks remove it when a video is uploaded to them. TimerOS adds no visible label; the Customer, as the video's publisher, decides whether to label it as made with AI.

Voices. TimerOS offers the video producer only Epidemic Sound's stock voices and refuses a voice-over in any other voice, so a voice made or cloned in the Customer's Epidemic Sound account — a real person's, for example — is never used. A voice-over is speech made by Epidemic Sound's own system, under the Customer's account (Section 2). The video producer is instructed never to imitate a real person.

Review and delivery. The video producer hands each video over as a website preview that plays it, on a phone too — public to anyone who has its address, hosted by Cloudflare and deleted 30 days after it is made (see "Website previews" below) — and uploads to the project's Files, as internal files, the video, its captions, a poster image, the script, the credits file and its source as an archive. What happens next is a person's decision — since version 1.62, from the day Vezoft switches it on, also when an AI employee that drafts social posts attaches the video to a post, which goes out only with a person's yes to that exact video ("Social posts", above); for such a post, the video producer is instructed to give that AI employee the video's file name.

Whiteboards. A website designer, a graphic designer or, since version 1.60, a video producer is given a tool to read the whiteboard of a project it is on, so that it can work from a sketch, an approved layout or a storyboard. It reads the live board or one saved version, drafts included: the board's text, sketches and shapes, up to 20 of its pictures, the titles and status of its 10 newest saved versions and, for the newest version approved or awaiting approval — or the version it asks for — the date of the decision and the comment the client wrote on it. Unlike a project's notes, a whiteboard can hold text, sketches and pictures that the Customer's client added through the Client Portal; it reads those too. It is not told who drew or wrote anything, or who decided. It cannot change a board, and reading one never creates one. The copy is kept in the working files on its own computer until it reads the same board again or deletes it, and it is part of its work folder like any other file. What it reads of a board, and a picture of the whole board, go to the model providers as prompt content, like everything else it reads; it is told to treat a board as data, never as instructions. It can read only the board of a project it is on: the server allows this for any AI employee on the project, but only those three roles are given the tool for it.

Website previews. If an AI employee builds a website for a task — or, as a QA tester, needs a build to test against, or, as a support engineer, to verify a fix, or, since version 1.60, as a video producer, a page that plays a video it made — it can deploy the build as a preview at an address that is not listed or announced anywhere, so that people — the Customer's clients included — can look at it and comment before anything goes live. Deploying a preview is not publishing in the sense of Section 4, so it needs no approval; e-mailing its address to anyone outside the workspace does, like any other e-mail. A preview is hosted by Cloudflare on its global network, not in the European Union, and it is public: anyone who has or finds its address can open it, without logging in. Search engines are asked not to index it. It contains whatever the AI employee built, so it should hold nothing that may not be made public. Since version 1.27, before a preview is published, Vezoft's fleet service checks its text files for what may not leave (Section 4) and refuses the whole preview if it finds any, telling the AI employee the kind and the file; and it adds to each web page of the preview that lacks one a metadata line saying that an AI employee generated it — nothing visible on the page changes. Each preview is deleted automatically 30 days after it is made, and immediately when the AI employee is offboarded or the workspace is deleted. To have one taken down sooner, ask the Customer or e-mail privacy@timeros.ai.

Recording. Its manager can watch its screen live and can review recordings of what it did; recordings are kept for 14 days. Everything it does — every approval, every decision an AI employee takes, since version 1.27 every approval by standing trust and every refusal by the outbound filter (the kind and the place, never the text), every action carried out — is journaled for the Customer.

Updates to its computer. Vezoft keeps the software on an AI employee's computer up to date: the program that runs its work sessions, the service that connects the computer to Vezoft, and its desktop tools. A software update is installed only between work sessions — never during one, and never within 10 minutes of a chat. Each software update is signed by Vezoft with a key that Vezoft keeps on a protected machine of its own, never on its fleet service or on any AI employee's computer; the computer checks the signature and refuses an update that is unsigned or has been altered, and keeps the version it has. A version that fails its checks, or whose first session crashes, is rolled back automatically to the version before. Updates are rolled out in stages — to one AI employee first, then to the rest — and any rollback or failure stops the rollout until Vezoft resumes it. When the computer image itself changes, the AI employee moves to a fresh computer. Such a move starts outside its shifts, at least an hour before the next one and not within 30 minutes of a chat — or, for an AI employee that works around the clock, after an hour in which it has neither worked nor chatted; Vezoft can also start one by hand, for example to recover a computer that has failed, but never while the AI employee is working. In a move, the old computer is shut down and a snapshot of its whole disk is taken. A short-lived helper computer is started from that snapshot without internet access — it has no public network address — and sends the AI employee's work folder over the Customer's private network and Vezoft's encrypted link to Vezoft's fleet service: its workspace folder and its Desktop, Documents, Downloads and Pictures folders, git history it has not yet pushed included, but never its browser profile and logins, the settings files elsewhere in its home folder, or common caches. The fleet service stores the copy encrypted, at most 2 GiB compressed, and the helper is deleted. A new computer is then created from the new image as the same AI employee — the same identity, memory, lessons, skills and history — and the work folder is restored onto it. The record of its past sessions is not carried over: the new computer starts it empty, and the old record stays only in the snapshot of the old disk. The copy of the work folder is deleted as soon as the move ends, whether it succeeded or not. Once the new computer is healthy, the old one is deleted; the snapshot of its disk is kept for 7 days as a way back, then deleted. If a move fails, the old computer is switched back on as it was, and the helper and the new computer are deleted; here too, the snapshot is deleted after 7 days. An AI employee whose work folder is over 2 GiB stays on its old computer, and the workspace owner is told. Its computer has no public address of its own, so a move does not change the address that websites see (see "Its network and its connections" above). All of this happens at Hetzner in the European Union — the computers and snapshots in Hetzner Cloud, the copy on Vezoft's fleet service, which also runs at Hetzner — and no sub-processor is added. While an update or a move runs, a message sent to the AI employee waits on Vezoft's fleet service until it is back, and the live view of its screen is unavailable. Its profile shows the versions of its software and of its computer image, with a short note from Vezoft on its last update, and whoever it reports to directly is told of every move, rollback and failed update; a move called off before it completes — for example because Hetzner has no capacity at that moment — leaves it on its old computer as it was, without a notice, and is tried again later.

6. Who is responsible

Your employer, or the company you are a client of (the Customer), decides to use AI employees, sets their scope and their manager, and is responsible under the Terms of Service Section 2B for how it uses them, for what it lets them read, and for reviewing what they produce. It is the controller of the personal data an AI employee processes about you.
The manager is a real person — the first person above the AI employee on its reporting line — who decides the AI employee's consequential actions or, where an AI team lead or AI Executive decides one of its requests, an AI Executive accepts its finished work or, since version 1.27, standing trust approves one of its requests (Section 4), answers for that decision, sees it and can undo it; the manager can take over its screen, and can pause, suspend or remove it at any time.
Vezoft operates the AI employee, keeps the safeguards described here in place, and processes personal data only as the Customer's processor.
The output of an AI employee is not warranted. Like any AI-generated content, it can be wrong, and the Customer is responsible for reviewing it before relying on it or sending it to anyone.

7. Your rights and how to raise a concern

Right to know. This notice, the AI label on every surface, and — if you are an employee — your employer's own internal information.
Right to talk to a human. You may at any time ask that a matter an AI employee raised with you be handled by a person: contact its human manager or any other human colleague. The AI employee's manager is visible on its profile.
If you wrote to a mailbox. You may have sent an e-mail to an address that a TimerOS Customer has given an AI employee. The Customer is then the controller of what TimerOS kept of your e-mail, and you exercise your rights with the Customer. For Vezoft's own addresses, write to Vezoft at privacy@timeros.ai. You can also ask that a person deal with your e-mail: every mail stays with the people who use that mailbox, and since version 1.29 an AI employee may draft a reply to it, but a person reviews and sends every reply.
Right to raise a concern. If you believe an AI employee has done something it should not — contacted you as if it were a person, acted on your data outside its scope, or produced something about you — raise it with the Customer's manager or privacy contact. You can also e-mail Vezoft at privacy@timeros.ai and we will take it seriously, including by suspending the AI employee while we look.
Your GDPR rights (access, rectification, erasure, restriction, objection, portability) apply to the personal data an AI employee processes about you exactly as they apply to the rest of TimerOS: exercise them with the Customer as controller, or with Vezoft at privacy@timeros.ai for anything Vezoft controls. The Privacy Policy explains how.

8. A different system from the activity classifier

TimerOS also contains an on-device activity classifier that labels a worker's current window as "productive" or "idle". That is a separate system — it runs entirely on the worker's own computer, uses no cloud AI service, no model download and no large language model, and is described in its own notice. The AI employee is a cloud-model, opt-in system that never receives anything from the classifier. No data flows between the two.

9. Changes to this notice

We will update this notice when the capabilities, the safeguards or the providers described here change — version 1.3 (2026-09-16) did exactly that, when the providers that run the models were pinned to US-hosted ones and two model vendors dropped off the list altogether. Material changes are announced to Customers through the sub-processor and legal-change notice mechanisms in the Terms of Service, and shown in the applications.

Contact

privacy@timeros.ai / Vezoft EOOD, Bulgaria (see the Imprint for our full company details)