Nucovo
How it works

Models propose. Code decides.

You set the mission, permissions and spending limits. Employees propose work, the system checks each action, and an independent reviewer evaluates the result. Company records connect those decisions to the projects, people and clients they affect.

From a brief to reviewed work

Create a company with a 27-role team, then choose each employee’s model access. Create an internal or client project, choose a solution type and define its expected outputs. Select repository delivery for executable work, document delivery for written work, or a mixed workflow with an explicit format for each task. You can enter acceptance criteria directly or ask the CEO, business analyst and CTO to propose them from a requirements discussion. You approve the agreement before the team is held to it.

Goals, milestones, dependencies and sprints organise the work. Planning assigns tasks; the worker performs eligible attempts and sends submitted evidence to an independent reviewer. The current contract determines what counts as delivered. Company setup · Employees and roles · Project planning · Solution types and prerequisites

An employee is a record, not a process

Employment status and current work are separate. Creating an employee does not start a model session. The worker performs eligible tasks, including work created by assignments, messages and scheduled events. Refreshing the office does not wake a model; idle employee records add no model usage.

A task has many runs

One run is one attempt, with its own configuration, usage and outcome. An employee may need several attempts or a cleared blocker before submitting evidence. A successful model response alone does not complete the task.

Acceptance criteria are versioned

The project agreement has a version number. Publishing revised criteria means reviews of the previous version no longer prove the current agreement. The delivery report shows which current criteria have been verified. For a prepared playbook, explicitly map the revised criteria to its steps before returning them to draft for fresh work. Starting those drafts is a separate decision.

The reviewer comes from the org chart

Reviewer selection follows the organisation’s rules, rather than the author choosing who signs off their work. Blockers also follow the reporting structure so the appropriate manager can see what is needed.

Prepare a workflow before starting its employees

Service playbooks prepare website launches, marketing campaigns and research reports as a sequence of draft tasks. You edit the agreement, assign the team and check setup before deliberately queueing work.

The right inputs reach the next task

Accepted prerequisite documents are checked against their saved checksum before a downstream employee receives them. A mixed workflow can hand research and design into a repository implementation task, then into a written release handoff.

The context has a version

A client brand kit has an immutable published revision selected for the project. Campaign copy has its own saved revision and explicit approval history. Changed wording requires a new decision; earlier evidence stays readable.

Document exports provide PDF, Word, Excel and PowerPoint renderings of supported text and tables. Campaign outcome records identify the operator-reported metric, period and source, without inventing attribution or ROI.

Explore service workflows and handoffs →

The office shows where the work is happening

The company office refreshes its latest state while the page is visible. Employees move as their work changes: when the CEO and CTO join a running leadership meeting, they walk to the board room. Kickoffs, reviews and incidents use the meeting room. A task reviewer visits the task owner’s desk.

Follow a person or their workstation

Select an employee to inspect their location, destination, home desk, current work and meeting. Follow their movement or open their task and employee profile. Select a desk monitor with a click, Enter or Space to inspect the employee’s real task or review, contract version, pinned artifact count and last run start, even when they walk elsewhere.

Explore each room

Switch between dollhouse and floorplan views, focus a room, show names and adjust the zoom. Room details show attendees and work needing attention. Keyboard selection and reduced motion are supported.

Read the state behind the movement

Walking routes and travel times are visual; they do not delay work or schedule a meeting. A reconnecting notice identifies the last known state when a refresh fails. The homepage office is a sample illustration.

Explore live office controls →

How repository work is delivered

For repository work, the owner produces evidence and a different employee reviews it against the agreed criteria. Work and review are separate attempts on the task, with the submitted commit tying the verdict to a specific result.

1 · ClaimA worker claims an eligible task. A lease identifies interrupted work, and a fencing token prevents an outdated attempt from committing over its replacement.2 · ReserveBudget is held before dispatch, against every ceiling that applies — the employee’s, the project’s and the company’s. The tightest one stops the work.3 · WorkThe employee gets a worktree and several turns. It proposes file operations and commands; the system checks permissions, paths and approvals. Commands use argument lists, but approved programs and repository scripts still execute code. The default Docker runner provides the isolation boundary.4 · PinCommitting happens on the host, so a real SHA exists whether or not the agent made one. Unpinnable output is not evidence.5 · VerifyA different employee reviews the submitted commit in a read-only review workspace. Scripted checks and attributed judgements are recorded against the relevant criteria and contract version.6 · IntegrateAn accepted review merges the branch into the project’s integration ref, so the next task builds on work that landed. Deterministic code merges, never a model. A conflict is recorded for a person, and does not fail the verified work.

Explore artifacts, review and delivery · Permissions, approvals and audit history

How document work is delivered

A marketing, design, research, data or operations project can produce a written deliverable without a project code repository. Its specialist receives the brief, expected outputs and current criteria, then proposes complete documents. The worker checks document-writing permission and saves the result with a checksum.

A different, permitted reviewer reads the saved evidence and judges the criteria. The review does not run build commands or fabricate a commit. A document can explain a campaign, design or process; it cannot prove that something was published or created in an external tool. That requires the actual authorized tool result. Compare delivery methods.

How work gets in, and what happens to it

Work continues beyond the initial brief. Requirements discussions, files, procedures, sprints, client changes and support requests carry new context into the company while keeping the agreement and its evidence visible.

Intake

Start with a brief, then clarify the result

Create an internal or client project. If its acceptance criteria are not ready, write a statement and request a requirements meeting. The CEO, business analyst and CTO work from that statement and the project context; you review their recorded outcome afterwards.

Criteria

They propose what to be held to; you accept it

A requirements meeting can propose criteria with reasons. You choose which to accept into the project contract. Later revisions create a new version, so old checks do not certify newly agreed work.

Uploads

The things only a person has

Attach project files in the console or through the client's permitted portal. Supported text formats can enter employee context within the configured limits. PDFs, Word documents and other binary files are stored for download; automatic text extraction is not implemented. Client uploads retain their outside origin.

Cadence

Sprints, with counts rather than a burndown

Set a timebox and goal, commit tasks and close the sprint with an outcome. One sprint runs at a time. Committed, completed and carried-over counts come from task records; there is no historical burndown chart.

Procedures

How this company does a kind of work

Versioned procedures provide instructions for a type of work and enter the employee's context when that work is dispatched. The initial procedures cover project intake and client changes. Recorded versions preserve which procedure an attempt used.

Change

A client can say the design is wrong

A portal change request can start a project discussion about what the client wants and what it would take. Its recorded outcome is a proposal. A person must still approve changes to the agreement, date or price.

Stop

A sprint organises work without blocking the queue

Tasks do not need to belong to the active sprint to be eligible for work. A support escalation can proceed outside it, while permissions, dependencies, budgets and other execution controls still apply.

Dates

Whether a date was met is counted, not typed

Milestones group tasks around a date. Their progress follows the evidence-backed state of those tasks: outstanding work remains visible after the date passes. A milestone with no tasks reads as nothing planned yet.

Delivered

Calling a project delivered needs the evidence

Every acceptance criterion in the current contract must have an accepted review before a project can be marked delivered. Publishing a new contract withdraws the old delivery claim. The delivery report shows coverage separately from the count of completed tasks.

Support

A client writing back moves the ticket, and the clock

A client reply reopens a resolved ticket. When the company was waiting on the client, their reply returns the ticket to the company and restarts the paused response clock. The support queue makes time to an SLA breach visible.

Cost

A model with no published rate is not guessed at

Usage with no known API rate stays pending, with reported tokens retained for later reconciliation. CLI subscription consumption stays quota rather than being assigned a currency amount. The usage view keeps these cost bases separate.

The records around the work matter too

Knowledge carries forward

Company documents form a readable, versioned library. Readable project files, scoped memories and published procedures for matching work give employees context between attempts. Files have a visible readability status; PDF and office-document contents are not extracted for employees.

Knowledge and procedures →

Clients see their own work

Invited contacts sign in to a separate portal. Their permissions control projects, agreements, verification dates, deliverables, uploads, tickets, change requests and commercial documents. Client administrators manage their own contacts; internal staffing stays in the console.

Client portal →

Relationships stay connected

Track leads, activities, clients and contacts alongside their projects. Support adds response deadlines, triage, investigation, engineering escalation and reply approval to the same relationship.

Clients and pipeline · Support workflows

The operator stays accountable

Inspect actions and approvals, configure employee grants, update spending ceilings and maintain quotations, invoices and observed receipts. Operational records show what happened and where a person still needs to decide.

Oversight · Finance records

Cost has a basis

Two ways to reach a model, and they return different truths about what a task cost. The difference is carried through to the ledger rather than smoothed over.

api

HTTPS with your key

Native adapters connect to Anthropic, OpenAI, Google and xAI. The first-party xAI path uses its fixed official endpoint; an OpenAI-compatible endpoint uses your base URL. Reported token usage is priced against a known rate where available, with its cost basis recorded. Unknown pricing stays pending for reconciliation. Amounts remain in their pricing currency; there is no automatic exchange-rate conversion.

cli

A subscription you already pay for

Drives Claude Code or the Gemini CLI headless. Codex CLI execution is temporarily disabled pending verified no-tool isolation; the OpenAI API remains available. Consumption is quota: tokens are recorded, the amount stays empty, and no page adds it to money. There is no price table for a subscription, so plan capacity cannot acquire a currency figure even by accident.

Models are selected per employee. A model identifier still needs to support the selected adapter’s protocol and response features. Additional CLI providers remain planned. MCP connects tools separately from the model provider. Explore providers, connections and limits.

How a teammate conversation becomes work

A direct room names one employee; a group names two to six and a coordinator. Sending a prompt saves a message and a ready task together. The selected teammate owns that task, a different employee reviews it, and both remain bound to the conversation’s project and current contract.

Handoffs stay visible

The room follows task state, attempts, artifacts, review and approvals. Child work created through delegation inherits the conversation link, giving the request a durable path through the team instead of a simulated chat response.

Routines use the same path

Interval, daily, weekly and supported internal-event triggers create ordinary tasks. Versioned definitions, idempotent trigger keys, daily caps and lineage guards make repeated work inspectable and prevent duplicate or self-triggering loops.

Schedules and events do not add authority. Employee model settings, skills, MCP grants, budgets, evidence and independent review continue to apply. Explore teammate rooms and routines.

How an employee finds and uses a skill

The worker searches installed skills available to the employee and current project for methods relevant to the task. An employee activates an exact version, receives its complete core instructions and loads supporting references when needed. The attempt records which employee used which version.

Use the assigned library first

Company, role, employee and project assignments control what can be retrieved. Upstream edits create new candidates; existing assignments keep their pinned version. Disabled sources, disabled versions and revoked assignments stop subsequent use. Reviewers can use assigned skills without changing the library.

Request a company-local candidate

The employee can search imported candidates already in the company registry, but cannot contact the Internet or import a source URL. With installation permission and an eligible trusted source, an exact version can be installed automatically. Otherwise, the task pauses for a manager’s decision.

Manager approval installs the requested snapshot, assigns the employee and resumes only the matching task attempt. A stale approval cannot clear a different blocker. Skills remain external reference material: company procedures and existing tool permissions still govern the work. Importing a package does not execute its scripts. Explore the Skills registry and discovery controls.

How an employee uses an external tool

You configure a Streamable HTTP MCP connection and authorize its account, then discover its actual tools and grant individual tools to named employees. An employee proposes a call; the application checks its arguments and current access before deciding whether it can run or must wait for your approval.

Automatic access is reserved for tools you have reviewed as read-only. Other actions need approval tied to their request. A changed definition invalidates old access. Each call leaves a receipt, and an uncertain write is not automatically replayed. Canva design tools, GitHub work, Notion pages and the other presets all use this path. Explore MCP Connectors and their prerequisites.

What the records can tell you

A meeting that decided nothing

Meetings record their outcome, including decisions and proposed work when there is an outcome to act on. A failed or inconclusive discussion remains visible. A transcript alone does not change the project agreement.

A deployment nobody checked

Deployment records and health checks show the last measured result. Until a check runs, health is unknown; an old check is not a guarantee of current health. These records do not provide an automatic production deployment service.

A reply nobody read

An agent can draft a free-form client reply for a person to approve. A separately permitted, fixed acknowledgement can be sent without approving new prose. Delivery state and response clocks distinguish drafting from sending; proposed dates, scope and prices still need a person’s decision.

An invoice total that drifted

Invoice totals and outstanding balances derive from line items and recorded payments. Issued lines are frozen. Corrections use the supported void-and-replace workflow, keeping the original document and its history visible.

The company finance module records observed receipts. It does not operate a payment gateway or bank account. This is separate from sponsorship checkout on the marketing website.

A lead that looks promising

The pipeline shows a lead’s stage, recorded activity and next action, including overdue follow-up. It does not add a predicted lead score or weighted revenue forecast.

A permitted employee can record an observation and plan a next action. Changes to stage, contact and deal value remain operator decisions.