The whole company.
Every part, explained.

Follow the setup steps to record a company name, mission, industry, founder objectives, country, legal form, currency, and time zone, with optional starting spending allowance.

The final review shows what will be created before the company is saved, then provisions the standard employee roles with their departments and reporting relationships in the new workspace.

First steps on the overview point to the remaining setup: add a project and start a configured worker before employees can begin carrying out tasks.

Open company settings to record the registered name, country, legal form, incorporation date, and registered address, then add the registration numbers relevant to that country's available catalog.

Registration entries display their stored validation state, with format or check-digit checks where implemented, so an obviously malformed identifier can be spotted beside the rest of the company's details.

These records document information you supply; creating a company here does not incorporate a business or confirm that a registration appears in an official government registry.

Choose a company and open its overview to see its project cards, current work, tasks needing a decision, and the people associated with the latest office state.

Charts summarize recorded runs, accepted work, and produced evidence, while the page separates priced spending, allowances, customer amounts owed, and pipeline figures into their appropriate views.

The overview also identifies a company that has never run work, giving you a practical starting point when an empty dashboard means the worker or first project still needs attention.

Open the command palette with Ctrl+K or Command+K to find companies, projects, tasks, employees, and documents by name, or jump to a section of the current company.

Use the sidebar to switch companies and review attention counts, press the question-mark key to see navigation shortcuts, and choose a light, dark, or system colour theme for the workspace.

Repository work produces source changes pinned to a commit. Accepted review permits integration into the project branch.

Document work produces complete written deliverables saved with checksums. A different employee judges the saved evidence against the current criteria; it does not need a project code repository.

The project type suggests a mode, but the operator can choose. Native design assets, live publication and external system changes still need actual authorized tools.

Write up to 32 expected output descriptions alongside the brief and chosen solution type.

The form offers domain-specific examples and judged criteria. Suggestions are not silently submitted: the operator deliberately adds and can edit each one.

Document projects use judged criteria. Leaving criteria empty preserves the requirements-first flow, with no planning dispatched until criteria are accepted.

Suggested delivery: repository. Example outputs: Website source and responsive pages; Content and accessibility review; Build and hosting instructions.

Review suggestions: The agreed pages contain approved content and working navigation The layout remains usable on the agreed mobile and desktop sizes The delivery includes reproducible build instructions and states which checks ran

Prerequisites: An accessible repository and required build tools Approved brand assets, content and licensed media Hosting and domain access if publishing is part of the approved scope

Suggested delivery: repository. Example outputs: Application source and database changes; Tests for the agreed user journeys; Setup and deployment notes.

Review suggestions: Each agreed user journey works with representative test data Access rules and error states are verified against the requirements Setup instructions describe configuration and checks actually performed

Prerequisites: A repository, runtime and test database Test accounts and permission to use required services A hosting environment for deployment; production changes need explicit authorization

Suggested delivery: repository. Example outputs: Mobile application source; Build and device test evidence; Signing and store submission checklist.

Review suggestions: The agreed flows are implemented for the specified platforms The handoff distinguishes device-tested behavior from untested behavior Build and release instructions name outstanding signing or store requirements

Prerequisites: The chosen mobile SDK and supported build host; iOS builds require macOS and Xcode A compatible emulator or physical device for device-level verification Owner-controlled signing certificates and store accounts for release; no store approval is guaranteed

Suggested delivery: repository. Example outputs: Application source; Platform build or packaging instructions; Installation and smoke-test evidence.

Review suggestions: The agreed functions are implemented on the named operating systems Installation and error handling are checked where a compatible host is available The handoff identifies untested platforms and signing prerequisites

Prerequisites: Compatible operating systems, runtimes and packaging tools A test host for each supported platform Owner-provided signing or notarization access when distribution requires it

Suggested delivery: repository. Example outputs: API or integration source; Interface documentation and examples; Authentication and failure-path tests.

Review suggestions: The implemented request and response contracts match the agreed specification Authentication, validation and retry behavior have documented evidence Examples and setup instructions identify external service dependencies

Prerequisites: Repository and service runtime Authorized test endpoints, credentials and representative payloads Explicit access to external systems; credentials are not supplied by the project type

Suggested delivery: repository. Example outputs: Automation scripts or workflow configuration; Dry-run evidence; Operating and recovery instructions.

Review suggestions: The workflow handles the agreed inputs without duplicating side effects Failure, retry and recovery behavior are documented and tested where possible The handoff identifies every external action that still needs approval or credentials

Prerequisites: A supported runtime and permission to access target systems Safe test inputs and an agreed schedule External tools or MCP connections must be configured separately; no physical tasks are performed

Suggested delivery: document. Example outputs: Analysis report with methods and limitations; Tables and metric definitions; Reproducible transformation plan or repository code.

Review suggestions: Every reported metric identifies its source, period and calculation Missing data, assumptions and uncertainty are stated The conclusions follow from the supplied evidence and avoid unsupported causal claims

Prerequisites: Authorized datasets with a documented meaning and permitted use Readable data or configured analysis tools; a narrative report does not execute a notebook Use repository delivery for executable pipelines and arrange the required runtime

Suggested delivery: document. Example outputs: Audience and positioning brief; Campaign or SEO action plan; Measurement plan and content calendar.

Review suggestions: The plan connects the target audience, offer, channels and measurable objective Recommendations cite supplied evidence and distinguish assumptions The plan identifies budget, approvals and account access required before launch

Prerequisites: A product brief, audience and business objectives Authorized analytics or research sources for evidence-based recommendations Ad spending, outreach and publishing require separately configured access and approval

Suggested delivery: document. Example outputs: Editable copy or script; Editorial outline and source notes; Publication checklist.

Review suggestions: The content follows the agreed audience, purpose, format and tone Factual claims are supported or clearly marked for verification The handoff includes the requested variants and remaining publication decisions

Prerequisites: Approved facts, brand guidance and source material Permission to use supplied text and media Publishing and sending to other people require separate approval and access

Suggested delivery: document. Example outputs: Design brief and visual direction; Screen or asset specifications; Editable asset links when an authorized design tool is connected.

Review suggestions: The design direction addresses the agreed audience, use and brand constraints The handoff specifies layout, content, accessibility and export requirements Produced assets are distinguished from specifications and linked only when actually created

Prerequisites: Brand assets, dimensions, reference material and usage rights Canva or another design tool needs an authorized connection and supported actions for native assets Document delivery alone produces a written handoff, not a guaranteed image, video or editable design file

Suggested delivery: document. Example outputs: Research brief with source references; Options and tradeoff comparison; Recommendations with uncertainty and next steps.

Review suggestions: The report answers the agreed question and identifies the sources available to it Facts, inferences and unresolved questions are separated Recommendations follow from the evidence and state their practical limits

Prerequisites: A defined question, decision context and permitted source material A configured research connection for live sources; model recall is not current verification Human expert review for decisions requiring professional judgment

Suggested delivery: document. Example outputs: Operating procedure or process map; Action plan with owners and dependencies; Templates and decision log.

Review suggestions: The procedure defines inputs, responsible people, steps and expected outputs Exceptions, dependencies and approval points are documented Recommendations distinguish proposed changes from actions actually taken

Prerequisites: The current process, responsible people and business constraints Authorized records and separately configured tools for actions in other systems Physical operations, legal signatures and financial commitments remain human responsibilities

Suggested delivery: document. Example outputs: The outputs explicitly agreed in the brief; Evidence and handoff instructions; Dependencies and remaining decisions.

Review suggestions: The deliverable addresses each agreed requirement Claims identify evidence, assumptions and any work that could not be performed The handoff identifies how to use the result and what remains for the operator

Prerequisites: A clear scope and an agreed delivery format The tools, data, accounts and runtime the work actually requires Unsupported or physical actions are reported as limitations, not represented as completed

Open the company office to explore a furnished layout with department desks, meeting tables, glass partitions, plants, seating, and shared areas arranged around a connected floor plan.

Employee figures represent the company's actual roster, with stable desk placement and visual working, meeting, available, and attention states that connect the environment to the work being recorded.

Record counters in the office link to the company's documents, evidence, decisions, and memories, giving the space useful navigation as well as the visual character of a working company.

When a running meeting includes an employee, the office moves that figure toward the meeting's room, while a task reviewer can visit the task owner's desk for the review.

Walking follows room doors and shared corridors, routes around the meeting and café tables, and can change direction from the current position when a newer work event changes the destination.

After the relevant state changes again, employees return to the appropriate desk or off-floor area; walking time illustrates those events and does not delay the underlying task execution.

The office displays active meeting objectives and participant lists beside the board room and meeting room, with room occupancy driven by meetings recorded as running in the company.

Leadership meetings use the board room, while other recorded meeting kinds use the meeting room, and the figures take seats around the conference table rather than standing on its surface.

Select a participant to inspect that employee, focus a meeting room to view it more closely, or open the meetings page to read the task and decisions behind the gathering.

Select an employee figure or a person in the office list to open an inspector showing their role, activity, home desk, current location, and work counts from the latest snapshot.

A current task card links directly to the work, and active meeting cards identify the objective of any recorded meeting involving that employee so you can investigate what they are doing.

The same panel offers the employee's full profile and a follow control, while attention lists and recently observed changes help you decide which person or task to look at next.

Switch between the angled dollhouse view and the overhead floor plan, focus a room from its header or the room selector, and adjust zoom to see the level of detail you need.

Follow a selected employee as their position changes, reset the camera to the whole office, toggle labels, or expand the view when the browser supports the fullscreen control.

Motion can be disabled from the toolbar, and the office honors the device's reduced-motion preference so the same employee and meeting information remains available without animated walking.

While the office is visible, it requests fresh snapshots about once a second after each successful update, refreshing employee activity, running meetings, and the office's record counters together.

The connection indicator and last-updated time explain whether the view is current, reconnecting, or paused, while the last known state remains visible if a request fails.

Polling pauses when the page is hidden and resumes when you return, and stale information stops driving walking animations so a lost connection does not keep presenting invented new activity.

Click a monitor or select it with Enter or Space to open that employee’s workstation, even when the employee has walked to another room.

The inspector shows the actual current task or review, task state, contract version, pinned artifact count and last run start. Shortcuts lead to the task evidence, project, workflow and release handoff.

Idle workstations say that no task is running. Disconnected data is labeled as a last-known snapshot. The monitor does not invent terminal output or simulate applications.

Open the organisation page to see the actual manager relationships and department groupings used by the company's employee records, then select a role to inspect its individual profile.

Role cards show availability and execution state alongside recorded accepted work, attempts, reviews, and usage, so you can distinguish an employee's responsibilities from what has actually happened.

The profile keeps configuration history, owned tasks, review assignments, and recent runs together, helping you trace a result back to the same employee even after their model configuration changes.

The organisation page compares the company's employees with the available role templates and identifies standard positions that have not yet been provisioned for that company.

Use the missing-roles action to add those positions with their template configuration and reporting relationships, while the employees already present keep their existing identity and accumulated history.

This helps an older company adopt roles added to the product's standard organisation over time, and gives you a concrete roster to review before assigning those employees work or adjusting their settings.

The current template has 27 roles. Eight additions cover the Chief Marketing Officer, Marketing Strategist, Content Writer, Designer, SEO Specialist, Research Analyst, Data Analyst and Business Operations Specialist. Existing employee identities, history and custom configuration remain intact.

Set the adapter, provider, model, base URL, descriptive tool list, and standing brief, then save the result as a new employee configuration version.

The model field accepts names beyond the installed suggestions, with unknown API pricing recorded as pending, and the history keeps earlier settings available for understanding past work.

Manage implemented capabilities for repository work, document writing, task creation and memory. MCP tool access is granted separately to named employees after discovery.

These grants are checked by the backend when an action is proposed, separately from the descriptive tools listed in the employee's instructions, and can be revoked as responsibilities change.

Change an employee's employment status and set how many tasks it may handle concurrently, while the organisation view shows the actual execution state independently.

The queue applies both the worker's overall concurrency limit and each acting employee's limit, including when that person is reviewing someone else's work.

The company inbox separates messages waiting for an answer from other messages, and shows their sender, purpose, recipients, time, and related task so you can understand the request before replying.

Answer in the existing thread and optionally choose a recipient, or mark an informational message as read when no response is needed to continue the work.

Replies to a task's question unblock that task for another attempt, where the worker can use the answer as context; the conversation remains available beside the work that prompted it.

Create a direct conversation for a project and choose its one teammate. The employee identity and coordinator remain explicit instead of being inferred from a company-wide feed.

The room keeps its messages and linked work together, so a later prompt continues in the same visible context.

A conversation belongs to one company and one project. It cannot be moved onto unrelated work after it has been created.

Choose a group of two to six active employees and designate one participant as the coordinator.

Membership is stored explicitly and checked as a transaction-level rule, including the participant count and coordinator membership.

The bounded group keeps the audience understandable and avoids turning private project work into a company-wide broadcast.

A prompt is saved together with a ready task. The chosen participant owns the work, a different active employee reviews it, and the task is pinned to the project's current contract.

The worker applies the same model configuration, permissions, allowance, dependency, attempt, evidence and independent-review rules used by work created elsewhere in the console.

Submitting a prompt does not pretend that a model has already replied. The conversation shows the durable work and its real state.

When linked work creates child tasks, those tasks inherit the originating conversation so the handoff remains visible beside the request.

The conversation timeline links to task state, attempts, artifacts, reviews and approvals rather than generating a separate unverified activity story.

A child task cannot be reassigned to a different conversation, and linked work must stay in the conversation's project.

Create an interval, daily or weekly routine for a project, select the acting employee and independent reviewer, and choose the time zone used for calendar schedules.

The worker claims due routines with idempotent trigger keys and creates ordinary governed tasks. It advances the next run from the current time so a long outage does not create a catch-up storm.

Pause or resume a routine, run an enabled routine immediately, or set a daily run cap. A paused routine rejects manual runs too. A schedule makes work eligible; it does not bypass the queue or review.

An event routine can respond to supported project, task, artifact, review, approval or meeting events and apply a small exact-match filter.

The created task receives a bounded snapshot labelled as untrusted trigger data. It does not receive an open-ended stream or authority from the event payload.

Lineage suppression prevents a routine from repeatedly triggering itself from the tasks it created.

Editing a routine creates another immutable definition version, while each claimed trigger records the version, source event or scheduled time and resulting task.

Uniqueness rules prevent the same trigger from being claimed twice. Daily limits and disabled or paused state are checked while the trigger is claimed.

History distinguishes created and skipped routine runs and retains each skip reason, so an automatic request can be traced back to its stored definition.

Start an internal or client project with a name, brief, solution type, delivery method and expected outputs. Supply a repository path for executable work; document projects use complete written deliverables.

If you already know the acceptance criteria, enter the conditions the work must satisfy and the company can queue a CEO planning task against that version of the brief.

If the criteria still need discussion, leave them for requirements intake; the project gives the company a shared place for its contract, tasks, files, milestones, evidence, and eventual delivery record.

Open requirements for a project to write what it must do, what you would reject, and the questions that still need a recommendation, then queue a meeting around that statement.

The CEO chairs the discussion with available specialist roles, producing a written understanding and proposed acceptance criteria that you can inspect, select individually, accept, or decline on the project page.

Only your acceptance publishes those proposals into a new contract version, and declined proposals remain recorded so the company can distinguish an agreed requirement from an idea it considered and rejected.

Publish a new contract version from the project page when the brief or acceptance criteria change, keeping the earlier versions readable as the history of what the company agreed to build.

Tasks remain pinned to the version they were created against, and the project highlights stale work because verification against the old requirements cannot establish completion against the new ones.

Use the project's re-pin action to move stale tasks onto the current contract before work resumes, and review the updated delivery report as fresh evidence is accepted for the revised criteria.

Create a company goal with a title, desired outcome, success conditions, and an optional responsible employee and target date, then associate the relevant projects with that goal.

The goals page shows how many projects serve it and how many of their tasks have been accepted, while preserving your written success conditions as the basis for judging the broader outcome.

When the result has actually been achieved or the company has decided to stop pursuing it, record that decision explicitly instead of treating a task count as an automatic percentage of business success.

Create a task inside a project with a title, description, owner role, and a different reviewer role, then either keep it as a draft or make it ready for the worker.

The task inherits its project's current contract context, and its page brings together the assigned people, acceptance conditions, dependency state, attempts, and evidence needed to understand its progress.

Project planning can also produce tasks for the team, but a task becoming ready only makes it eligible for dispatch; the worker still checks dependencies, employee availability, and the other conditions required to run.

Use the company's task list to review work by status, and open a project's board to see that project's tasks grouped by their actual progress through execution and review.

When planning creates dependency relationships, the project shows what waits on what, while each dependent task links directly to the predecessor tasks and their current completion states.

The worker only claims dependent work once its prerequisites are completed, and finishing a prerequisite makes downstream work eligible to continue, giving the visible dependency structure a real effect on execution order.

Open a task to inspect its blocked reason and any suggested remedy, adjust its numerical priority to influence queue order, or release a draft when the description is ready.

After resolving the cause of a blocked, failed, or cancelled task, retry it to allow additional attempts while retaining the earlier run history and the evidence those attempts produced.

Cancellation stops unfinished work from continuing under its current claim, while provider rate limits have their own visible waiting state so temporary capacity problems are not presented as a completed or failed piece of work.

Plan a sprint for a project with a goal and start and end dates, then start it when the team is ready and commit relevant tasks from the available work.

The sprint view shows accepted work, committed tasks, remaining time, and items needing a decision, with task links that let you inspect the actual reason something has stopped.

Only one sprint can be active for a project at a time, and sprint membership organises planning rather than acting as an execution gate, so eligible project work can still run without belonging to a sprint.

When a sprint ends, close it with an outcome describing what happened, so the period leaves a useful retrospective record beside the tasks that were committed to it.

Unfinished tasks stay associated with that sprint until you explicitly carry them into a planned next sprint, giving you a chance to decide what still deserves a commitment.

Completed work remains in its original sprint history, allowing later reviews to distinguish what was accepted during the period from the work that continued after the team reassessed its plan.

Add named milestones to a project, optionally give them due dates, and assign relevant tasks to those milestones from each task's controls as the delivery plan becomes clearer.

The project displays milestone state and associated work, making it possible to compare a promised checkpoint with the tasks that still need to be performed or accepted.

Update a milestone's status when the checkpoint changes, using its date as a planning commitment while retaining the separate evidence and review requirements that determine whether the underlying tasks or project can be called complete.

Schedule a project meeting with an objective, a bounded agenda, a chair, and selected employee participants, so the discussion has a concrete question to answer before it enters the queue.

The worker holds a limited number of rounds, records what the participants said, and asks the chair to produce decisions and follow-up work or explain what could not be settled.

A meeting uses the same task, attempt, budget, and independent review machinery as other work; the meetings page shows its status and links to the transcript captured on its task.

Open meetings and decisions to read recorded decisions with their statement, rationale, effective date, project context, and the number of tasks that were created from the decision.

The view distinguishes decisions that remain in force from ones superseded by a later decision, and preserves recorded objections so disagreement does not disappear from the company's history.

Meeting cards also show unresolved questions and whether the session produced any decisions, helping you decide when an additional discussion is needed instead of assuming that a completed transcript means the team reached agreement.

Choose a service, write its brief, edit the suggested acceptance checks and explicitly accept the agreement. The playbook prepares draft tasks with named producer and independent reviewer roles, task delivery formats and dependency edges.

Website launch combines research, copy, design, implementation and release handoff. Marketing campaign covers audience evidence, strategy, creative specifications, copy, measurement and handoff. Research report covers scope, source evidence, analysis, report and decision handoff.

Creating a playbook project does not call a model, hire missing employees, grant tools or publish anything. Its saved playbook and agreement versions remain visible.

A mixed project can contain repository tasks and document tasks. Each prepared step names its format and solution domain rather than guessing from the project label.

Repository tasks use source files, commits and applicable executable checks. Document tasks produce checksum-pinned written evidence with independent judgment. A mixed task must choose a concrete format before it can start.

This makes the implementation task different from the strategy, content or research handoff that supports it. External asset creation and deployment still require actual capabilities.

The workflow checks the current agreement, assignments, company and employee state, required action grants, model configuration, allowances, and required repository and runner setup.

Checks explain what is ready, blocked or still requires confirmation. A configured credential is configuration evidence, not a successful request to its provider.

Missing external account access, mobile SDKs, devices, signing and other task-specific prerequisites still need the operator. Readiness does not promise the requested outcome is achievable.

A prepared workflow begins as draft tasks. Assign the available employees and reviewers, review its criteria and resolve blocked checks before starting it.

Starting checks setup again and queues eligible drafts. The worker follows the dependency order, and every completed task still needs independent accepted evidence at the current agreement version.

A setup check, role assignment or start request never silently grants tools, opens provider accounts or approves publication.

Create a campaign for a specific project and objective. Each calendar item records exact copy, its channel, a planned date and optional pinned evidence from that same project.

Saving edits creates another immutable content revision. The calendar shows the latest revision; earlier wording and decisions remain in its history.

Dates are planning records. The campaign module does not schedule social publishing, send email or authorize ad spending. Archive finished planning and reopen it when needed.

Review a saved item and explicitly approve its current revision. The decision pins a content checksum and attached artifact metadata. An edit creates a new draft that needs its own approval.

Approval refuses stale revisions, changed source metadata and mismatched content hashes. Approving document attachments in the console also checks their current bytes against the saved checksum.

Other attachment snapshots identify recorded evidence; metadata alone does not verify file bytes, a live URL or publication. Approved for handoff never means that content was sent or published.

Enter a metric, precise decimal value, unit and measurement period, with a source description and HTTPS link or project artifact. The record retains its source metadata and the time it was entered.

Values are labeled operator reported. The system does not fetch the linked report, independently verify it, calculate automatic return on investment or assume the campaign caused the result.

Mistaken observations can be voided with a reason while their original values remain visible. Add a corrected entry instead of rewriting measurement history.

When the project agreement changes, review and explicitly accept how its current criteria map to the existing playbook steps.

The operation preserves task history and valid assignments, then returns the steps to draft, including previously completed steps. Active work or reviews must settle before the mapping can change.

Starting the revised drafts remains a separate action. Old artifacts and approvals do not automatically satisfy the new agreement.

Once an eligible task is claimed, its owner produces work and evidence, after which the assigned reviewer checks the result against the task's pinned contract and acceptance conditions.

A review that requests changes sends work back through the appropriate implementation path, while accepted evidence allows the worker to complete the task without treating a successful model call as proof of completion.

Open the task's evidence chain and review history to see which completion conditions are met, which remain pending, and what the reviewer actually said about each version of the result.

Write acceptance criteria with a stable identifier and a clear statement, adding a command when a requirement can be measured by an executable check rather than a reviewer's judgment.

During review, scripted criteria take their result from the command's exit code, while judgment criteria receive a recorded reviewer assessment with the evidence used to reach that verdict.

The task page displays each criterion's pass, fail, or not-checked state and its checking method, making it possible to find the specific unmet requirement instead of relying on a general claim that the work succeeded.

A task's evidence table records artifacts with a commit, checksum, or preview reference, together with the available branch, path, size, and creation time needed to identify the output.

The inspector reads supported file content or a commit diff back for you and reports whether it can verify the evidence, with checksum mismatches or missing content shown as a problem.

Use the task's evidence and review sections together to connect a verdict to the precise output that was assessed, rather than assuming that a file currently on disk still represents the reviewed result.

For a project that produces viewable static files, set a preview path inside its repository so the worker can capture that file or directory after a run.

The task and delivery views link to the captured preview when one exists, and the serving path checks the saved files against their recorded checksums before returning them.

A preview is a read-only snapshot of static output, so you can inspect a generated page or report while keeping clear that this feature does not launch an application server or publish a live deployment.

Repository tasks start from the project's integration branch, and after a review accepts a commit the worker attempts to merge that accepted branch so later work can build on it.

If the commits conflict, the task's accepted evidence remains intact while the approvals page identifies the branch, target commit, and files that Git could not reconcile.

Resolve the conflict in the repository and record that you have done so in the app; that acknowledgment records your decision and does not itself perform or independently verify the merge.

Open the project's delivery section to see every current contract criterion, the task covering it, its accepted reviewer, and the available commit reference, then open the generated report for a portable account.

The project can be marked delivered only when its nonempty set of criteria has the required accepted evidence at the current contract version, and the operator makes that delivery decision explicitly.

Reopen the project if needed, or publish changed requirements to withdraw the old delivery claim; a fresh contract requires verification against the new promise before the project can be delivered again.

On a task's evidence table, use the sharing control for the specific artifacts that are ready to be exposed through the associated client's project experience.

Artifacts start as internal, and the same control can stop sharing an item later, allowing you to distinguish the agreed deliverable from intermediate output or internal working material.

When a client has approved an artifact or requested changes, the task displays that response beside the item, helping the operator review the feedback in the context of the exact evidence that was shared.

Completed prerequisite tasks supply reviewed document evidence from the same agreement version. The worker reads the files inside the artifact directory and checks each saved checksum before including the handoff.

Missing, changed or oversized handoffs stop the transfer with a clear reason. Large source sets must be split rather than silently shortened.

Accepted code is identified by commit and integration reference; the next employee must inspect the actual repository when using it. Handoff text remains untrusted reference material and cannot grant permissions or change scope.

Convert document evidence into PDF, Word, Excel or PowerPoint using supported text, headings, lists and tables. Download metadata distinguishes the original source checksum from the converted file checksum.

These are alternate renderings of reviewed source. Exporting does not create new accepted evidence or turn a design specification into a native Canva design, image or video.

Remote assets, arbitrary HTML, spreadsheet formulas and macros are not executed. Conversion is bounded by size, time, memory and concurrency limits; unsupported input produces an error while the original source remains available.

The project handoff shows current acceptance criteria, recorded independent reviews, accepted document or commit pins, and local source verification. It identifies missing or changed sources and makes bounded or incomplete checks visible.

Compare accepted source references with the project's deployment records and their last recorded HTTP health observations. A matching reference does not prove which version a live host serves, and a health observation describes availability at its recorded time.

Download the handoff as Markdown, inspect outstanding release prerequisites and review earlier accepted pins as recovery references. Historical references are not reverified or a tested rollback plan. Opening or downloading the handoff does not publish, run a new HTTP check or perform a rollback.

Publish a document with a stable key, title, scope label, and body, then reuse that key when you want to create an updated version of the same document.

The knowledge page groups the newest version with its earlier versions, allowing you to read past wording, timestamps, and available meeting provenance when you need to understand how a statement changed.

Documents provide a durable library for people using the company; publishing a document alone does not change task state, permissions, budgets, or the work instructions supplied through the separate procedures system.

Attach a file and an explanatory note from the project page, then see its size, whether it came from you or a client, and whether employees can read its contents.

Supported text formats such as plain text, Markdown, CSV, JSON, and YAML can be supplied to workers as bounded project context, with long content truncated explicitly when needed.

Other formats, including PDF and Word files, can be stored and listed but are not parsed for employee context by this feature, and the row explains that limitation so important requirements are not assumed to have been read.

Record a memory item in the knowledge area with its content, kind, scope label, and optional source reference, using company scope for notes you want available as general company context.

The memory list preserves the kind, author, source, and recorded time so an operator can tell a user-provided statement from an employee observation or a proposed interpretation.

Remove an item when it should no longer remain in the company's memory, and use the visible provenance when deciding whether the note deserves to guide a later task or needs to be checked first.

Before applicable work, the worker recalls the company's memory along with entries addressed to the current project, department, or employee, prioritising user-provided and observed material within the configured context limit.

An employee with memory-recording permission can propose notes from its work, which are stored with the employee and originating run and returned as unverified context on later applicable attempts.

This keeps useful information available across runs while preserving its source and scope, and expired entries are excluded from recall instead of silently continuing to influence work after their recorded lifetime.

Write a procedure with a stable key, title, body, and the supported kind of work it governs, then save it as a draft until you are ready to make it active.

The worker attaches an active procedure when its work type matches, and records the exact procedure version on the attempt so later inspection shows which instructions were in force at that time.

Publishing a replacement retires the earlier active version while retaining its history; drafts and guidance without a matching work type do not automatically reach employees, keeping publication an explicit operating decision.

Use the procedures page to adopt the available standard set as drafts, giving the company an initial collection of working guidance to review before any of it affects employees.

The adoption action skips keys the company already has, so a procedure you have written is not replaced by a template when you add other missing guidance.

Review each draft, revise it under the same stable key when necessary, and publish or retire versions deliberately; the list makes the current in-force version and retained history visible for each procedure.

Browse public source listings shared across your Nucovo installation, including starter listings for the Anthropic and Vercel skill collections.

Imported instructions, assignments, policy, requests and usage stay within the company. Finding or importing a source does not publish it to the marketplace.

An operator can explicitly publish public source metadata for other companies on the installation to discover. A listing is a starting point for inspection, not a permission grant or an endorsement of every package.

An operator enters a public GitHub repository, directory or file URL, or a direct public HTTPS URL ending in /SKILL.md. Select a specific directory when a collection is too large to inspect at once.

Source inspection shows skill summaries, resource counts, compatibility notes and import diagnostics. Choose which exact snapshots to save as candidates, then open a candidate to review its complete instructions, references, source revision, supplied license and requirements before installation.

Imports support bounded text packages; missing required files or unsupported resources prevent a package from being installed as a complete supported skill.

Each saved version preserves complete core instructions and supported text resources. GitHub imports resolve to a commit; checksums identify the imported text snapshot.

Importing an update creates a new candidate. Existing assignments keep their exact version until an operator deliberately changes access.

The importer stores resources as inert text and never runs bundled scripts or installers. Disabling a source or version stops future use while retaining snapshots and usage history.

Assign an exact installed version to a named employee, an employee role, a project or the whole company. Installation and assignment are separate operator controls.

The employee page shows applicable skills, and retrieval checks the employee and current project before offering instructions. Removing access prevents subsequent retrieval and activation.

An automatic installation grants the version to the requesting employee only. A manager can broaden its assignment after reviewing where else it belongs.

PostgreSQL full-text search matches task terms against skill names, descriptions, instructions and resources already in the company registry. Company visibility and live assignments filter results before relevance ranking; employee queries never become Internet requests.

An agent activates a relevant exact version to receive its complete core instructions, then reads supporting resource pages as needed. Core instructions are never silently shortened.

This retrieval-augmented generation (RAG) uses lexical relevance, matching words and terms. It needs no separate vector database and does not claim embedding-based semantic search.

Only operator actions in Marketplace and Sources can contact the Internet for skill discovery, inspection or import. Employee and model runs search only the company-local registry and cannot submit a source URL.

The operator chooses a fixed capability and public GitHub or optional Brave Search. The server supplies the exact generic query, so company, client, task, identifier, URL and secret text cannot enter the provider request.

The operator saves an exact public result or known source, inspects it and chooses which pinned snapshots to import. GitHub search is subject to its rate limits; broader web discovery requires SKILLS_BRAVE_API_KEY on the console.

Keep automatic installation off to require operator approval, or allow compatible versions only from sources an operator explicitly enabled and trusted.

Automatic installation also requires the employee's installation permission. Agents cannot trust a source themselves, change policy, revive rejected versions or expand their own assignments.

Installation checks current policy and permissions without granting credentials, command access or MCP tools. Imported instructions remain external reference material within company procedures.

When an installation needs approval, the employee creates a durable request for the exact version and its task pauses. The request records who needs the skill and why.

Approval installs that snapshot, assigns it to the requester and resumes the matching waiting task attempt. A stale approval cannot clear another blocker; rejection leaves a clear reason for the pause.

Activity records discovery and installation decisions, while usage history links employees and runs to exact versions. Review the record when changing assignments or disabling a skill.

Record the company you are talking to, the person to contact, an expected close date, and a dated next action so someone clearly owns the follow-up.

Expected values are figures you enter, and the pipeline keeps currencies separate so an early estimate remains distinguishable from an offer or an invoice.

Move a lead through new, qualified, proposal, and negotiation stages as you make those decisions, with stage changes recorded in its history.

Winning creates a linked client record in the same action, while losing requires a reason; the original lead stays available with its notes and related quotations.

Add a short account of what happened and when it happened, rather than trying to reconstruct a deal from its current stage alone.

The timeline distinguishes your entries from employee observations and automatic stage records, so a colleague's interpretation does not silently become an established fact.

Choose the project that should carry the work and request an employee review of the lead's history through the normal task queue and budget controls.

The employee can record an observation and suggest a next step, while stage changes, deal values, and contacting the prospect remain under your control.

Keep client notes and named contacts with email addresses and roles, then follow the links to tickets, invoices, engagements, repositories, and portal logins.

Track whether the relationship is a prospect, active, paused, or churned; marking it churned closes portal access for that client's people while retaining the record.

Create project, support, retainer, or internal engagements with the commercial model, currency, status, and term dates that apply to the agreement.

Keep an open-ended engagement when that is what was agreed, or use an end date to surface upcoming renewals alongside the services recorded for that client.

Record a repository name, URL, and default branch on the client so the team can identify the intended codebase when setting up and reviewing work.

These repository records sit beside engagements and support history, while actual task execution uses the project repository configured on the installation.

A kit contains logo and asset references, colors, typography, tone, approved product facts, prohibited claims and usage rights. Existing file and document references are checked against the company and client; HTTPS links remain references and are not fetched automatically.

Edit a draft, review its saved contents, then explicitly publish it. Published revisions cannot be changed or deleted. Copy a published revision into a new draft for changes.

A font name does not install or license a font, and a written rights statement does not grant asset usage rights. Concurrent edits cannot silently overwrite the newest saved draft.

A project explicitly selects a published kit revision belonging to its client. The worker and reviewer receive that exact guidance and source checksum as reference material.

Publishing another kit revision does not update existing project selections. Choose guidance before queueing work; once work at the current agreement is queued, started or completed, changing the selection requires a new contract version.

The database serializes task activation with changes to the brand selection. A selected kit cannot grant tools, authorize publication or rewrite earlier accepted evidence.

Open a ticket on a client's behalf with the original subject and message, or receive it when an authorised client starts a conversation in the portal.

Each ticket keeps its conversation and links to related internal work, giving you a place to understand both what the client said and what the company did next.

Assign an employee and set urgent, high, normal, or low priority after reviewing the request, then track triage, active work, waiting, resolution, and closure.

Requests can be reopened when a problem returns, and resolving one requires completed linked fixes or an explanation of why no code change was needed.

Configure first-response and resolution times for each priority on the client's engagement, and show the resulting due dates on the ticket queue and detail screen.

Waiting for the client pauses the service clock, and a client reply resumes it; an engagement without a policy is shown without an invented deadline.

Choose the project that should carry the triage task so the same queue, spending limits, and review process apply to this support work.

A support pass can draft a reply, adjust permitted working states, and escalate a bounded set of tasks to developers, with its proposed actions and rejected actions recorded.

Create linked fix, investigation, or follow-up tasks from the ticket and open their task pages to see the owner, attempts, review, and resulting evidence.

A fix link means resolution depends on that work, keeping a reassuring support message from silently standing in for a verified repair.

Write a reply yourself or review one drafted by an employee, then approve or reject it from the ticket or the shared outbound queue.

Draft, approved, sending, and sent states remain distinct, and the client portal shows the conversation's sent messages rather than unfinished internal drafts.

When an SMTP transport is configured, send an approved message to the client's recorded address and retain the transport result with the conversation.

Without a mail transport, the operator can record that they sent the reply themselves; the interface distinguishes that statement from an application delivery attempt and shows uncertain in-flight sends.

Enable the acknowledgement on the client record to allow the installation's fixed receipt message when a ticket is opened on that client's behalf.

The receipt does not count as the promised first response or authorise arbitrary employee-written mail, and portal-created conversations already confirm receipt on screen.

Create a quotation for a client and optionally link the lead it came from, then edit its title, terms, notes, and individual items while it is a draft.

Totals are calculated from the items, with discounts applied before tax, so the offered amount can be explained from the actual work and prices recorded.

Sending a quotation assigns its number, freezes its items, and publishes it in the client portal with a validity date; viewing and client decisions are recorded.

An accepted offer can be converted once into an itemised invoice draft with discounts resolved into the copied prices, while withdrawn and lapsed offers retain their history.

Start an invoice for a client, optionally associate an engagement, and edit the draft's details and lines before assigning its invoice number at issue.

Issued lines stay frozen, while delivery can be recorded and a void retained as an explicit outcome, so later edits do not silently rewrite what the client was billed.

Record a receipt after someone has observed the payment, and calculate paid and outstanding amounts from those receipt records rather than typing a paid status.

An invoice becomes paid when recorded receipts cover its total, while open balances stay grouped by currency; this is billing recordkeeping and does not move money or connect to a bank.

Choose a company currency, maintain the tax rates you use, and apply the appropriate rate to each quotation or invoice line so the document’s total can be explained from its items.

Quotation and invoice lines carry the selected tax figures, while rates can be retired from future use; the installation does not decide your tax obligations or convert currencies automatically.

Apply a money budget or subscription-token ceiling to the whole company, an individual project, or an employee, and check every applicable allowance before dispatching an attempt.

The worker reserves capacity before starting and settles or releases it afterward, helping concurrent tasks share the remaining allowance without each assuming the entire balance is free.

Break usage into input, cached input, cache creation, and output where the provider supplies those counts, and follow entries back to the run that consumed them.

API money, estimated or pending costs, and subscription quota remain visibly separate, so tokens used against a plan are not presented as an additional provider invoice.

Unknown model pricing stays pending instead of being treated as free, and you can enter a real amount later when the corresponding charge is available.

The usage screen also shows the reservations currently holding allowance and the budgets they affect, helping distinguish money already consumed from capacity still reserved by unfinished work.

An approval names the proposed action, affected resource, requester, task, and the exact content being authorised so you can assess what will happen before deciding.

Approved requests are consumed once and expire, while changed content requires a new decision; the record preserves pending, approved, rejected, expired, and used outcomes.

Pausing prevents the queue from assigning new work while allowing current attempts to finish and receive their normal verdicts.

Halting also stops lease renewal so active attempts abort and return unfinished work to the queue, with a recorded reason; lifting a halt preserves any separate pause already in place.

Use the activity view to inspect the company’s recorded events and the actors associated with them, then follow the related work to understand why a change happened.

Attempts, review outcomes, and operating decisions retain their history instead of disappearing when a task advances. Questions that need your response appear separately in the operator inbox.

The security screen separates employee, operator, client, and system activity, and lists successful and failed portal sign-ins with time-based counts and current account lockouts.

Source addresses are labelled as claimed request information rather than proven identities, so the view supports investigation without inventing a risk score or promising automatic intrusion prevention.

The console reads the company's records without requiring employees to be running, while a separate worker starts the queued model work when you run it.

Company records, artifacts, and configuration live on the installation, with the client portal served as a separate application; calls to an external model provider still send the task context that provider needs.

Configure an employee to use the Anthropic, OpenAI, Google, or xAI API adapter, with credentials supplied by your installation and the requested model recorded on its configuration version.

Each adapter translates task context and results into the common work format, and reports usage using the provider's available token information and the installed pricing data.

Choose the xAI provider, configure XAI_API_KEY on the installation, and select an xAI model such as grok-4.6 for the employee's versioned model configuration.

Requests use the fixed official api.x.ai endpoint. The run records the model actually returned by the provider and separates available cached and uncached token usage for the ledger.

This is model access inside Nucovo's own task, evidence and review system. Grok Bot's hosted persistent computer, live takeover and private product orchestration are not claimed as public xAI API capabilities.

Select Claude Code or Gemini CLI and let the worker invoke the installed, authenticated tool under its required isolation settings. Codex CLI execution is temporarily disabled until a verified no-tool isolation path exists; OpenAI API access remains supported.

Claude Code requires safe-mode, strict MCP and tool controls; Gemini CLI currently requires the verified 0.47 release family without conflicting managed system settings or policies. Incompatible installations are refused. Supported runs retain the existing account sign-in and record subscription usage as quota rather than an API invoice price.

Choose the compatible API provider and configure its endpoint, with an optional installation credential, to use services that implement the OpenAI wire format expected by the adapter.

This makes compatible hosted or local model servers configurable without adding a separate provider adapter, while actual model support and behaviour still depend on that endpoint.

Tasks have separate attempts, renewable leases, and ownership checks so abandoned work can be reclaimed without a stale worker overwriting its replacement.

Provider rate limits delay another attempt, and supported CLI work can continue a token-limited session within the current attempt when turns remain; this is bounded continuation rather than a promise to restore every old provider session.

Docker execution uses a task worktree with a read-only container filesystem, reduced privileges, resource limits, and an explicit network setting, while model credentials stay in the worker.

Command results, code changes, and test reports become pinned evidence for review; a separate local execution mode is available for development and carries weaker isolation.

Give each connection a name, kind, declared scopes, and a reference to where its credential lives, without pasting the credential itself into the company record.

The settings view shows its recorded state, last check, and action counts, while actual provider credentials and service setup remain part of configuring the installation.

Record an existing deployment, run a check immediately, or set a per-service interval for the worker to check it, with health derived from the latest measured result.

The view distinguishes unchecked, healthy, slow, and failing services and shows upcoming engagement renewals; registering a service does not provision infrastructure or deploy application code.

Streamable HTTP connections support GitHub, Playwright, Figma, Notion, Atlassian and Canva presets, plus custom endpoints.

A preset supplies connection guidance, not an authenticated account. Remote servers use HTTPS; local HTTP needs explicit loopback permission and a server started separately.

The company does not inherit personal CLI MCP settings or launch arbitrary local server commands.

Discovery records names, descriptions, input schemas and a definition hash. Tool availability depends on the remote service, account permissions and entitlements.

Arguments are checked against supported schemas before dispatch. Changed definitions or configuration invalidate old access and require review again.

A server's descriptive or read-only annotations remain untrusted input; they are not standing authority.

Access binds an employee to a specific tool, configuration version and definition hash.

Calls default to approval tied to the exact request. Automatic access is reserved for tools the operator has explicitly reviewed as read-only.

Revoking a grant or disabling a connection removes future access. It cannot recall a request already sent to the remote service.

OAuth connections use a local console callback and provider consent. Credentials are stored encrypted with the installation key and used by trusted application processes.

Bearer-token connections reference dedicated MCP_ environment variables rather than storing pasted tokens in connection metadata.

Canva custom clients need redirect-URI allowlisting; Figma requires an approved client in its MCP Catalog. A supported protocol cannot bypass provider onboarding or account policies.

Call records retain the request identity and bounded response with pending, succeeded, failed or unknown outcomes.

An uncertain write is not automatically replayed: the remote service may have acted even when its response was lost.

Tool outputs remain untrusted material when fed back into employee context. A recorded call does not establish that every claim in the response is true.

Owners and admins can review project work and make client decisions, members can collaborate and read quotations, and billing contacts are limited to invoices and quotation decisions.

Only an owner manages colleagues, and every view uses the signed-in client's scope, with overview activity respecting the same role permissions as the underlying pages.

Project pages show the current agreement and its acceptance items, with verified outcomes tied to that version instead of a manually entered percentage.

Milestones show their recorded dates, completed task counts, and standing, while shared deliverables and the client's uploaded files appear beside the project they concern.

Only artifacts explicitly shared by the company appear in the portal, with their project, available preview or commit reference, and recorded client decision.

Owners and admins can approve or request changes with a note, while that client verdict stays separate from the company's internal review and evidence requirements.

Owners, admins, and members can upload a file with a note to one of their own projects, with a two-megabyte limit and a visible record of what was sent.

Supported text formats can become employee context, while PDFs, office documents, and images are retained with an explanation that their contents were not extracted for the agents.

Authorised contacts can start a question, bug report, change request, or incident and add later messages, while the company sets the service priority after reading it.

The portal shows the client's messages and replies actually marked sent, keeps internal drafts private, and resumes a waiting ticket's service clock when the client responds.

A project change request creates a queued requirements discussion involving the relevant company roles, so the request goes through the normal budget, ownership, and review process.

The resulting discussion can produce decisions and tasks for the company to consider, while submitting the request does not itself agree to a new scope, price, or delivery date.

The portal presents published quotation items, terms, totals, and validity, with acceptance or rejection available to owners, admins, and billing users while members can read only.

Invoice access is reserved for owners, admins, and billing users, who can see issued amounts, recorded receipts, and what remains due without a payment checkout being implied.

Clients can inspect where their account is signed in, review recorded sign-in outcomes, and end every other session while keeping the one they are using.

Access uses expiring sessions and single-use password-setup or reset links, with suspension checked on later requests; link delivery is handled through the installation's current operator workflow.

A client can begin setup, add the supplied secret to an authenticator, and confirm a code before the second factor becomes required for future sign-ins.

The implementation rejects reused accepted codes and requires the password to remove the factor, with encrypted-secret configuration supplied by the installation before this feature can operate.

Owners can invite a colleague, assign owner, admin, member, or billing access, and change or suspend other colleagues while keeping their historical decisions attached to their accounts.

The interface returns a password-setup link for deliberate private sharing, and the owner-management rules preserve an active owner and prevent changing the currently signed-in account through that screen.