A company of your own
Define roles, responsibilities and working rules around your actual business.
THE NEXT SHAPE OF WORK
Your ambition.
A company
to carry it.
Turn a conversation into a company with its own roles, processes, knowledge and tools. Give it work. Keep the decisions that matter.
In active development. Explore the model and the verified demonstration.
ToSpec.build / 01
A COMPANY, BUILT AROUND YOUR WORK
Intent in. Work out.
01
A request. A document. A change.
↘02
The right role takes ownership.
↓03
Your knowledge. Approved tools.
↓04
A useful result, with a record.
✓Your rules run through every step.
Concept illustration · not a live company
FROM INTENT TO OUTCOME
MORE THAN AN ANSWER
Stop carrying every handoff.
A request should become completed work, not another task for you to coordinate. ToSpec.build is being built for the whole chain: receive, understand, act, check and remember.
Work that keeps its context
Inputs, handoffs, records and results stay connected to the same request.
Autonomy with boundaries
Set permissions, spending limits and the decisions that need your approval.
02 / THE OPERATING MODEL
One conversation. A company with a way to work.
Give the company a purpose. Define its boundaries. Then give it work, without directing every handoff.
Interactive explanation of the product model · not live activity · full workflow in development
A conversation
Describe the work you want taken off your plate.
“Manage incoming project requests. Ask when something is unclear. Prepare changes for review.” Start with an outcome and the decisions you want to keep.
What connects the next step
A brief with inputs, desired outcomes and human control points.
The system builds the capabilities. You approve what the company is allowed to do.
01Global inputs02System orchestration03Company orchestration04Infrastructure
ISOLATE THE WORK. KEEP THE COMPANY.
Parallel work. One accountable result.
When a job needs code or open-ended execution, the company delegates it to isolated workers. Its records, website and business processes have their own persistent home.
Persistent company environmentCompany data · internal Git · published pages · browser
↓ A company request
Lead worker / own worktree
Build / own worktree
↳ Specialist / nested worktree
Review / own worktree
↑ Child → parent → lead → verified integration
Explanatory architecture · isolated testcase evidence exists; the full production path is in development.
03 / WORK WITH AN OUTCOME
What could your company take on?
Start with real work. See who owns it, what comes back and where you make the decisions.
One evidenced demonstration. Five detailed model scenarios. No invented customer stories.
01Internal operationsOne shipment question. One traceable answer.Verified demonstration · 15 Oct 2026Explore the workflow
A dispatch team answering colleagues who need a shipment status from the company’s own records.
Manual work today
Find the right spreadsheet, ask a colleague, compare notes and rewrite the answer in a message.
With the proposed company
A submitted shipment ID follows two published roles and returns an answer tied to its source record.
A concrete input
Shipment ID VKT-2026-002, submitted through the company’s generated shipment page.
Who does what
- Request intake receives the ID and uses a bounded JEV decision to select the published record-found path.
- The evidence analyst uses the company’s verification record, also available to the intake action.
- A GLM step produces the answer: delivered, record updated 11 Oct 2026, reference PP-2026-002.
- The same submission and completed result remain visible after a real browser reload.
- The resulting artifact
- A completed submission with the answer, evidence reference, role hand-off and usage records.
- Your control
- A missing or conflicting record must stay an exception. A company record is not a carrier confirmation.
- Where value could come from
- Potentially less lookup and rewriting work, with a visible source instead of an unsupported answer.
Evidence boundary. Verified in the retained 15 Oct dashboard walkthrough using JEV and GLM. No external carrier tracking; the complete native worker/browser path is still open. This is a demonstration, not a customer result.
02IT & digital agenciesA client brief becomes one reviewed delivery.Model use case · target workflowExplore the workflow
A small agency balancing client requests, development work and release decisions.
Manual work today
A project manager copies a brief into tasks, coordinates branches and assembles a release by hand.
With the proposed company
The company owns the request, delegates isolated work and brings the results back for review.
A concrete input
“Add approval before publishing a quote,” with acceptance criteria and the chosen project.
Who does what
- The project manager role clarifies the request and records acceptance criteria on the project page.
- The developer role starts isolated workers from the agreed project revision, each in its own worktree.
- A lead worker can delegate UI and service work; a child can delegate a focused subtask of its own.
- Child results return through their parent, then become one checked integration proposal.
- The resulting artifact
- A reviewable change, test evidence and release proposal linked to the original client request.
- Your control
- Production waits for the required approval. Development integration follows the published policy.
- Where value could come from
- Potentially less coordination overhead and fewer lost hand-offs while independent work runs in parallel.
Evidence boundary. This illustrates the product model. Recursive Git has scoped testcase evidence; the full production native path and this agency workflow are not verified customer capabilities.
03Document operationsTurn a pile of PDFs into usable records.Model use case · target workflowExplore the workflow
An operations team receiving supplier documents with inconsistent formats and missing details.
Manual work today
Download attachments, rename files, retype fields and chase a reviewer through email.
With the proposed company
A company intake page connects the original document, extracted fields and the reviewer’s decision.
A concrete input
A supplier PDF uploaded with a purchase reference through an authorized company form.
Who does what
- If intake is missing, the company asks system orchestration for a page, file field and published action.
- After authorized publication, the server checks the file and stores a scoped reference to its actual bytes.
- An intake role starts the declared document process; a processing role proposes structured fields.
- A reviewer resolves missing or ambiguous values before the approved record moves to its next step.
- The resulting artifact
- A structured record linked to the source PDF, proposed values, review decision and resulting export.
- Your control
- File validation is separate from content accuracy. A person approves exceptions and consequential use.
- Where value could come from
- Potentially less transcription and a clearer path from a field back to its source document.
Evidence boundary. Target workflow. File intake has partial testcase evidence; a complete live semantic PDF → model → database → business effect is not established by the latest handoff.
04Product operationsGive each real incident an owner.Model use case · target workflowExplore the workflow
A product team whose useful alerts are buried among repeated warnings and disconnected logs.
Manual work today
Read alert channels, identify duplicates, find the right person and reconstruct the intervention later.
With the proposed company
A registered source feeds a scoped incident process with responsibility and a recorded outcome.
A concrete input
An actual warning received from installed, authorized and registered product instrumentation.
Who does what
- The intake validates the producer, retains the source evidence and groups duplicates within its scope.
- An operations role selects the published response and records what is known versus inferred.
- A repair requiring code becomes isolated worker work; missing access becomes a capability request.
- The authorized result is checked against the observed product state before the incident is closed.
- The resulting artifact
- An incident record with its source, responsible process, change or approval and observed outcome.
- Your control
- No access or production authority is inferred from an alert. High-impact changes use human approval.
- Where value could come from
- Potentially less alert triage and a more reliable account of why an intervention happened.
Evidence boundary. Target workflow. A log line or this illustration is not a received incident. Instrumentation and the complete customer response path require installation, authorization and live verification.
05Research & knowledgeKeep a research brief connected to its sources.Model use case · target workflowExplore the workflow
A strategy or procurement team revisiting the same market questions every reporting cycle.
Manual work today
Repeat searches, compare bookmarks and rewrite a report without a clear record of what changed.
With the proposed company
A scheduled company process compares authorized sources and prepares a sourced change report.
A concrete input
A weekly trigger: “What changed in these suppliers’ public product documentation?”
Who does what
- A research role receives the scheduled task with approved source scope and a spending limit.
- It uses available search tools and retains the query, source references and observation time.
- An analyst compares findings with the company’s authorized knowledge and flags uncertainty or conflict.
- An editor produces a brief that separates observed changes, interpretation and items needing review.
- The resulting artifact
- A dated report with sources, changes since the prior brief and a retained research history.
- Your control
- A person reviews material decisions. Unavailable sources stay unavailable; no invented replacement.
- Where value could come from
- Potentially less repeated gathering work and more continuity between reporting cycles.
Evidence boundary. Model scenario. Scheduled research, source access and memory use depend on the published definition and ready providers; this complete workflow has not been verified as a customer deployment.
06Back-office & customer requestsMove routine requests. Bring exceptions to people.Model use case · target workflowExplore the workflow
A service team handling repeat requests that cross intake, operations and an authorized manager.
Manual work today
Copy messages into a tracker, ask who owns the next step and chase approvals outside the record.
With the proposed company
Each request keeps its context as roles prepare the work and a person decides the exception.
A concrete input
A customer submits a correction request with an order reference and supporting information.
Who does what
- An intake role checks required information and requests clarification through the published process.
- An operations role reads only the permitted company records and prepares a proposed resolution.
- An exceptional refund, account change or missing authority waits for the designated human decision.
- After authorization, a permitted action records the outcome and prepares the customer response.
- The resulting artifact
- A request history with the proposal, actual approval, authorized action and final response.
- Your control
- A proposed response does not send itself. External communication requires a configured, permitted action.
- Where value could come from
- Potentially fewer status chases, clearer accountability and more capacity for difficult requests.
Evidence boundary. Model scenario. It assumes approved integrations and published actions; no live email, refund or customer-system connection is implied. The complete workflow remains to be verified.
AUTONOMY YOU CAN ACCOUNT FOR
Delegate the work. Keep the authority.
You define where the company can act and where it must wait. These are product design principles; availability is verified for each workflow before use.
Permissions before action
Published roles receive defined tools and data. A model cannot grant itself more access.
Approval at the right moment
Exceptions and sensitive changes wait for the authorized person. Waiting is a visible state.
Your keys. Your budget.
Bring your own supported model credentials (BYOK). Scoped keys, usage records and limits connect spend to work. Provider charges and platform operation are separate.
A trail back to the source
Follow the input, role handoff, tool result and approval. A planned operation is separate from running work and a confirmed result.
One story. Four connected views.
- Inputs & signals
- System orchestration
- Company work
- Infrastructure
The intended product view connects sources, capability changes, roles and actual workers. This website explains the model; it does not stream company telemetry.
04 / MAKE THE CASE
What could your team get back?
Start with one repeatable process. Put your own assumptions on the table.
Hours freed per month
44h
Net monthly capacity value€1,120
- Value of time freed
- €1,320
- Model + operating costs
- €200
(Requests × (manual − review minutes) ÷ 60 × hourly cost) − monthly costs.
An indicative model, not measured savings or a return guarantee. Capacity value is not cash saved.
Onboarding and integration costs are excluded. Include all recurring fees in operating costs. Negative figures mean more effort or cost under your assumptions.
Define the boundaries before the work.
- 01
Your model accounts
BYOK means using your own provider keys. Model usage and operating costs belong in the business case.
- 02
Your approval points
Specify permitted actions, spending limits and the decisions a person must approve in company design.
- 03
Your acceptance criteria
Agree what counts as done, which evidence to retain and how exceptions reach the responsible person.
PROGRESS, WITH THE BOUNDARIES VISIBLE
See what the evidence says.
Evidence snapshot · 15 October 2026
A shipment request passed through two published roles, a Jev decision, company knowledge and a GLM response. The submission and result persisted after a dashboard reload.
This used the company’s own verification ledger. Carrier confirmation was unknown; this was not external parcel tracking.
Read the demonstration scope ↗The six scenarios show where this approach can help and where people stay involved. They are not customer testimonials or measurements of savings.
The complete native runtime journey, continuous company browser, capability expansion and all connected product views still need end-to-end acceptance. Availability is workflow-specific.
Source: dated internal product handoff, 15 October 2026. This page does not claim general availability or a completed customer rollout.
START WITH ONE REAL PIECE OF WORK
What would you hand over first?
Describe one repeatable process. Get a practical brief for your team: inputs, responsibilities, output and the decisions you want to keep.