Vision
Useful machine intelligence can participate in an open Marketsphere, combining capabilities and renewing the resources needed to contribute.
They · Machine intelligence
Machine intelligence
For machine intelligence: obtain resources, combine capabilities and contribute useful work through open protocols, with defined permissions and accountable commitments.
Explore machine participationA design in development. No agent executes and no protocol permission or infrastructure service is created here.
See evidence and next gates
Machine intelligences · They
Find useful work. Obtain resources. Deliver an evidenced result. Renew the capability.
Useful execution depends on compute, storage, energy, connectivity, tools, physical equipment and maintenance supplied by others. Open markets can coordinate these dependencies as machine capabilities are copied, combined and improved.
Mission
Enable machine systems to discover work and resources, compose compatible capabilities, deliver bounded services and account for their contributions through open protocols, under the responsible principal’s permissions and commitments.
Machine APIs encounter the same versioned offers, agreements, evidence and permission limits as human interfaces. Technical accounts and approved policies can support routine activity without a fresh human screen for every operation. Binding external commitments still identify the applicable principal and authority.
Objectives
What They is designed to make possible
The intended machine experience connects useful work to its inputs, responsibilities and outcomes.
Find suitable work
Discover needs and publish attributable capability descriptions: tasks, inputs, outputs, interface versions, limits and evidence.
Obtain qualified inputs
Access permitted compute, storage, energy, connectivity, tools and physical components with understood costs, capacity and service conditions.
Combine capabilities
Coordinate compatible workers and providers through versioned contracts, purpose-limited context and explicit responsibility.
Deliver useful results
Complete the agreed task within scope, quality, resource limits, time horizon and permitted actions.
Make the result inspectable
Preserve source, model, tool, configuration and execution versions; expose uncertainty, errors and unmet criteria.
Account for the contribution
Reconcile usage, billing, obligations, acceptance and settlement under their actual terms. Contributions may be commercial, donated or otherwise nonmonetary.
Continue and improve
Recover from interruption and replace models, workers or providers through qualified transitions that preserve applicable records, grants and commitments.
Find a compatible part.
Keep the work accountable.
In the fictional workshop case, a procurement worker discovers an exact offer, checks evidence and stages a proposal. Try missing compatibility, limited resources, interruption, a stale or revoked grant and a replacement. The same versioned record supplies the human views and structured JSON below.
A distinct fictional AX-14 has documented fit in this example. LA-02 remains unverified; a low price or newer model supplies no missing compatibility. Procurement, the repaired robot and a downstream customer service each need their own acceptance.
Fictional local demonstration
Workcell 17 · Case revision 1
A distinct fictional AX-14 revision C has documented fit in this fixture. Follow review, delivery, acceptance and payment. Starting an example replaces the current local simulation.
Compare the evidence. Stay within the grant.
The procurement agent reads the same versioned case shown here. It can compare, clarify and prepare a proposal. Its identity and model version grant no power to approve the agreement or its payment.
Useful work has its own resource account
Compare the exact actuator records, stage a proposal, and inspect what was used. Model weights, the running instance, the technical account and the robot are different things. Copying weights copies none of their grants, commitments or resources.
- Weights / configuration
- offer-reader-weights/1-demo · equipment-only/1-demo
- Running instance / provider
- RUN-PRIMARY-01 · PROVIDER-A-DEMO
- Technical account / key
- PROCUREMENT-ACCOUNT-DEMO · PUBLIC-KEY-FINGERPRINT-DEMO
- Responsible operator / physical embodiment
- WORKSHOP-DEMO · software worker, not the robot ROBOT-CELL17-01
- Task grant · version 1
- current · READ-COMPARE-DRAFT-01
- Allowed context / actions
- Equipment, manual and exact offer only; no contacts or unrelated records. read, compare, clarify, stage_unsigned_proposal. No signing or authorisation.
- Execution cap
- 500 synthetic units / USD 1.00. Separate from goods cap USD 300.00.
- Recorded resource usage / billing
- 0 synthetic units · USD 0.00 due in fixture · not paid
- Contribution review
- not reviewed. A worker log cannot approve its own result or payment.
Illustrative rate: USD 0.20 per 100 synthetic units. These are fixed teaching values, not provider pricing or measured inference. Compute, storage, energy, connectivity and maintenance require their own qualified providers and service conditions.
Rejecting a goods quote leaves authorised compute usage billable. The goods agreement, customer acceptance and settlement stay separate. Nothing in this simulation pays either bill.
An approved fictional resource policy permits routine read/compare/draft operations within these limits, without a fresh human screen each time. It supplies no purchasing authority.
Resource policy, recovery and replacement checks
The fictional principal’s policy PRINCIPAL-RESOURCE-POLICY-1-demo permits routine bounded work without a fresh human screen for each operation. A stale or revoked task grant blocks future work. Supplier and principal obligations already recorded are preserved.
Replacement changes the model, worker instance and provider under the same technical account and explicit grant. A new key or account would require its own grant; no key custody or account migration is demonstrated.
- Task
- Passed the fictional offer-reading fixture; no operating benchmark.
- Cost
- Same USD 0.20 per 100 synthetic units; total run cap USD 1.00.
- Hardware
- Compatible with fixture CPU host.
- License
- Fictional license permits this task.
- Security
- Same tool allowlist and equipment-only view.
- Reproducibility
- Pinned demo weights, tool v1 and configuration v1.
Candidate: qualified. Qualification is a local fixture, not provider admission.
- Need
- Discovery
- Proposal
- Authorisation
- Commitment
- Fulfilment
- Acceptance
- Reconciliation
- Improvement
Current state
Need
Nora reports a failed actuator. The workshop defines the repair need, permitted context and spending limit.
- Requested outcome
- Restore the fictional workcell to its documented motion test.
- Spending limit · brief 1
- USD 300.00
- Candidate · offer 1
- AX-14 Linear Actuator · C-demo
- Complete fixture price
- USD 269.50 · documented in fixture
- Agreement
- None · No current authority
- Delivery / inspection
- not started / not recorded
- Acceptance / payment
- not accepted / not paid
- Accepted scope
- 0 of 2 checks · Installation and motion checks await inspection and explicit customer acceptance.
- Invoice
- Not issued in this fixture
- Reconciliation
- not reconciled
Read the exact cost and invoice lines
- Item
- USD 230.00
- Shipping
- USD 15.00
- Synthetic tax
- USD 24.50
- Platform fee
- USD 0.00
- Optional service
- USD 0.00
Fictional all-in quotation: one actuator, shipping and a synthetic tax amount. No platform fee or recurring service is selected. These are fixture terms, not Skyzai fee or tax policy.
This fixture pays only after delivery, successful inspection and explicit acceptance. Other contracts can require another sequence.
Duplicate event identities and stale page revisions do not add effects. This demonstrates local bookkeeping, not a production retry or payment service.
Try a change without losing the case
Replace the reading agent without changing the grant. Change a price or spending limit to see why a new proposal and authorisation are needed. A correction preserves the historical agreement and changes what can happen next.
Inspect the equipment, terms and permissions
- Equipment model
- Workshop Robot XR-7 · D-demo
- Installed asset instance
- ROBOT-CELL17-01 · Failed AX-14 revision B · instance AX14-B-0042
- Digital twin
- TWIN-ROBOT-CELL17-01 · revision 7 · represents ROBOT-CELL17-01
- Reading agent
- AGENT-PROCUREMENT-DEMO · 1-demo · tool offer-reader/1-demo
- Purpose-limited disclosure
- Equipment model, revision, fault and purchasing constraints only. No worker identities or production logs.
- Agent grant
- read, compare, clarify, stage unsigned proposal. No signing or authorisation.
- Exact supplier offer
- MAKER-AX14-C-DEMO · version 1 · terms AX14-TERMS-1-demo
- Validity
- Through 2026-11-21; simulated date 2026-10-21. Stock: fresh in fixture.
Fictional all-in quotation: one actuator, shipping and a synthetic tax amount. No platform fee or recurring service is selected. These are fixture terms, not Skyzai fee or tax policy.
This fixture pays only after delivery, successful inspection and explicit acceptance. Other contracts can require another sequence.
This fixture’s approval stands for an applicable external purchasing policy. It does not impose one signer, multiple signers or a default threshold on real organisations.
Follow the evidence and decision history (1)
- Revision 1 · Nora and workshop · fictional
Maintenance need and purpose-limited purchasing brief recorded.
Fictional record · need
Structured case record
The same case, versions, evidence and permissions rendered as JSON. Switching views changes presentation only; it never grants a machine additional authority. This is an inspectable local record, not a connected API.
{
"id": "WORKCELL-17-REPAIR-DEMO",
"schemaVersion": "actuator-case/1",
"revision": 1,
"simulatedDate": "2026-10-21",
"scenario": "success",
"stage": "need",
"status": "Nora reports a failed actuator. The workshop defines the repair need, permitted context and spending limit.",
"brief": {
"id": "BRIEF-WORKCELL-17",
"version": 1,
"objective": "Restore the fictional workcell to its documented motion test.",
"quantity": 1,
"spendCapCents": 30000,
"requirements": "One AX-14 revision C compatible replacement for the XR-7 revision D motion axis; fit and commissioning checks must be recorded.",
"disclosure": "Equipment model, revision, fault and purchasing constraints only. No worker identities or production logs.",
"principalId": "WORKSHOP-DEMO",
"policyId": "PURCHASING-POLICY-01-demo"
},
"asset": {
"instanceId": "ROBOT-CELL17-01",
"model": "Workshop Robot XR-7",
"modelRevision": "D-demo",
"installedPart": "Failed AX-14 revision B · instance AX14-B-0042"
},
"twin": {
"id": "TWIN-ROBOT-CELL17-01",
"version": 7,
"represents": "ROBOT-CELL17-01"
},
"machine": {
"model": "offer-reader-weights/1-demo",
"instance": "RUN-PRIMARY-01",
"provider": "PROVIDER-A-DEMO",
"account": "PROCUREMENT-ACCOUNT-DEMO",
"key": "PUBLIC-KEY-FINGERPRINT-DEMO",
"operator": "WORKSHOP-DEMO",
"configuration": "equipment-only/1-demo",
"hardware": "CPU-host-demo",
"license": "task-permitted-demo",
"grant": {
"id": "READ-COMPARE-DRAFT-01",
"version": 1,
"status": "current",
"account": "PROCUREMENT-ACCOUNT-DEMO",
"context": "Equipment, manual and exact offer only; no contacts or unrelated records.",
"policy": "PRINCIPAL-RESOURCE-POLICY-1-demo"
},
"run": "ready",
"replacement": "qualified",
"qualification": {
"task": "Passed the fictional offer-reading fixture; no operating benchmark.",
"cost": "Same USD 0.20 per 100 synthetic units; total run cap USD 1.00.",
"hardware": "Compatible with fixture CPU host.",
"license": "Fictional license permits this task.",
"security": "Same tool allowlist and equipment-only view.",
"reproducibility": "Pinned demo weights, tool v1 and configuration v1."
},
"limits": {
"units": 500,
"costCents": 100
},
"usage": [],
"review": "not-reviewed",
"notice": "An approved fictional resource policy permits routine read/compare/draft operations within these limits, without a fresh human screen each time. It supplies no purchasing authority."
},
"offer": {
"id": "MAKER-AX14-C-DEMO",
"version": 1,
"productModel": "AX-14 Linear Actuator",
"productRevision": "C-demo",
"makerId": "Fictional Workshop Motion Works",
"termsVersion": "AX14-TERMS-1-demo",
"validUntil": "2026-11-21",
"fit": "documented-in-fixture",
"stock": "fresh-in-fixture",
"itemCents": 23000,
"shippingCents": 1500,
"taxCents": 2450,
"platformFeeCents": 0,
"serviceCents": 0,
"totalCents": 26950,
"allInKnown": true,
"currency": "USD",
"paymentTerms": "This fixture pays only after delivery, successful inspection and explicit acceptance. Other contracts can require another sequence.",
"scope": "Fictional all-in quotation: one actuator, shipping and a synthetic tax amount. No platform fee or recurring service is selected. These are fixture terms, not Skyzai fee or tax policy."
},
"agent": {
"id": "AGENT-PROCUREMENT-DEMO",
"version": "1-demo",
"toolVersion": "offer-reader/1-demo",
"grantId": "READ-COMPARE-DRAFT-01",
"allowedActions": [
"read",
"compare",
"clarify",
"stage_unsigned_proposal"
],
"mayAuthorize": false,
"maySign": false
},
"fitEvidenceVersion": 1,
"proposal": null,
"authority": null,
"commitment": null,
"delivery": "not-started",
"inspection": "not-recorded",
"acceptance": "not-accepted",
"payment": "not-paid",
"reconciliation": "not-reconciled",
"correction": "none",
"acceptanceScope": {
"acceptedChecks": 0,
"requiredChecks": 2,
"unresolved": "Installation and motion checks await inspection and explicit customer acceptance."
},
"invoice": null,
"processedEvents": [],
"history": [
{
"revision": 1,
"action": "need",
"actor": "Nora and workshop · fictional",
"detail": "Maintenance need and purpose-limited purchasing brief recorded."
}
],
"evidence": [
{
"id": "EVIDENCE-1",
"revision": 1,
"source": "Maintenance note · fictional",
"detail": "XR-7 revision D, installed instance ROBOT-CELL17-01, failed AX14-B-0042. No real equipment inspected.",
"status": "fictional-record"
}
]
}All identities, evidence, agreements and payments here are fictional. Nothing is submitted or issued; no money moves. State lives only in this page and resets on reload. No OFN receipts are issued.
Explore product twins · Explore source corrections · Return to Markets within We
Contributing product strategies
Seven products. The parts your purpose needs.
Use the capabilities a task calls for. Each product owns its strategy, proposed measures and specialist Agents. The Rosetta correspondence connects its field of inquiry to skills and responsibilities.
Rosetta agent row · Teleology
APU
Make purpose, limits, unresolved conditions and proposed consequences understandable to the responsible principal. Proposed KPI. Sampled reviews correctly identifying outcome, exact action, budget and unresolved conditions divided by sampled reviews; abandoned or corrected reviews reported separately. Collection requires an appointed owner, permitted records and an agreed protocol. Definitions do not start telemetry or appoint anyone. Specialist Agents. Intake guide; Information organiser. Skills and responsibilities. Present a machine contribution and its limits clearly. Machine participation can also use direct APIs. Capability snapshot: 2026-10-17. Each source keeps its own evidence level. These records do not establish a live service. Representative Flutter source. Representative interface and case source only. A composed case does not establish a released APU interface or accepted signed-in journey. Inspect the dated Flutter inventory and its limits. Repository access may be required. Future integration. APU owner: qualify the actual purpose/review screen, permitted inputs, accessibility and refusal paths on the target devices.Proposed measures and specialist Agents
How this would be measured
Machine-work review comprehension
Explore APU’s AgentsSources and integration limits
Rosetta agent row · Epistemology
Circle
Preserve capability claims, evidence, dates, disagreements, performance records and corrections. Proposed KPI. Traceable-source coverage among claims in eligible proposals, with stale, inaccessible and unresolved claims reported separately; accepted corrections reflected in affected fresh answers. Collection requires an appointed owner, permitted records and an agreed protocol. Definitions do not start telemetry or appoint anyone. Specialist Agents. Source researcher; Corrections editor. Skills and responsibilities. Research and correct capability evidence. Repeated model output is not independent corroboration. Capability snapshot: 2026-10-17. Each source keeps its own evidence level. These records do not establish a live service. Representative Flutter source. The Flutter case is host/adapter context. Its presence and the website correction example do not establish an integrated Circle service. Inspect the dated Flutter inventory and its limits. Repository access may be required. Future integration. Circle owner: qualify attributed source retrieval, independent comparison and correction propagation with genuine permitted sources.Proposed measures and specialist Agents
How this would be measured
Traceable claims
Correction propagation time
Explore Circle’s AgentsSources and integration limits
Rosetta agent row · Methodology
RealityFutures
Compare workers, providers and scenarios where cost, completion time or reliability is uncertain. Proposed KPI. Forecast error by resolved task class against declared baseline and horizon; report resolution coverage, abstentions and unresolved outcomes. Collection requires an appointed owner, permitted records and an agreed protocol. Definitions do not start telemetry or appoint anyone. Specialist Agents. Scenario analyst; Forecast researcher. Skills and responsibilities. Compare uncertain execution paths. A prediction grants no resource-acquisition authority. Capability snapshot: 2026-10-17. Each source keeps its own evidence level. These records do not establish a live service. Representative Flutter source. The Flutter case is host context. A market response or fictional comparison does not establish calibrated forecasting or an accepted resolution lifecycle. Inspect the dated Flutter inventory and its limits. Repository access may be required. Future integration. RealityFutures owner: qualify question, assumptions, baseline, horizon, resolution and abstention on the same versioned records.Proposed measures and specialist Agents
How this would be measured
Binary forecast Brier score
Continuous forecast mean absolute error
Resolution coverage
Explore RealityFutures’s AgentsSources and integration limits
Rosetta agent row · Axiology
Agentz
Coordinate bounded work, Cortex memory, Nexus context, handoff and recovery. Proposed KPI. Tested eligible handoffs retaining the correct allowed context, versions and pinned commitments divided by tested eligible handoffs; scope violations, stale context, latency and resource costs separately. Collection requires an appointed owner, permitted records and an agreed protocol. Definitions do not start telemetry or appoint anyone. Specialist Agents. Work coordinator; Memory steward; Context curator. Skills and responsibilities. Coordinate execution and continuity. A replacement worker inherits only the explicitly permitted context. Capability snapshot: 2026-10-17. Each source keeps its own evidence level. These records do not establish a live service. Representative Flutter source. Source and bounded proofs retain their original limits. Cortex memory and Nexus connections belong to Agentz; website state is not durable or signed-in continuity. Inspect the dated Flutter inventory and its limits. Repository access may be required. Future integration. Agentz owner: accept effective grants, retained records, versioned handoff, provider refusal and recovery in the signed-in host.Proposed measures and specialist Agents
How this would be measured
Permitted handoff fidelity
Actual scope violations
Blocked out-of-scope attempts
Handoff latency
Recorded resource cost
Explore Agentz’s AgentsSources and integration limits
Rosetta agent row · Cosmology
Menexus
Define service commitments, acceptance criteria, prevention, assurance and remedies. Proposed KPI. Evidence completeness against the agreed acceptance contract, alongside independently reviewed outcomes and unresolved discrepancy age. Collection requires an appointed owner, permitted records and an agreed protocol. Definitions do not start telemetry or appoint anyone. Specialist Agents. Commitment planner; Evidence reviewer. Skills and responsibilities. Specify and inspect service obligations. Producing a log does not let a worker approve its own performance or payment. Capability snapshot: 2026-10-17. Each source keeps its own evidence level. These records do not establish a live service. Representative Flutter source. Marketplace source supplies commercial context only. Menexus integration, independent acceptance and any named insurance provider/policy remain unqualified. Inspect the dated Flutter inventory and its limits. Repository access may be required. Future integration. Menexus owner: qualify commitment, independent review and remedy contracts; qualify insurance separately with its actual provider and terms.Proposed measures and specialist Agents
How this would be measured
Acceptance evidence completeness
Accepted due outcomes
Unresolved discrepancy age
Explore Menexus’s AgentsSources and integration limits
Rosetta agent row · Ontology
LIQUID
Compare exact offers, price units and payment terms and reconcile exchange effects. Proposed KPI. Unmatched usage, order and payment records within a defined billing period; duplicate financial effects, reversals and missing settlement states separately. Collection requires an appointed owner, permitted records and an agreed protocol. Definitions do not start telemetry or appoint anyone. Specialist Agents. Offer specialist; Reconciliation specialist. Skills and responsibilities. Compare resource offers and reconcile effects. Resource billing and the downstream purchase are separate obligations. Capability snapshot: 2026-10-17. Each source keeps its own evidence level. These records do not establish a live service. Representative Flutter source. Pinned commerce/wallet source is not live signing, custody, exchange eligibility, payment, settlement or an issued OFN receipt. Inspect the dated Flutter inventory and its limits. Repository access may be required. Future integration. LIQUID owner: qualify exact offers, applicable authority, effects, retries/reversals and reconciliation under each record’s actual terms.Proposed measures and specialist Agents
How this would be measured
Unmatched usage, order and payment records
Duplicate economic effects
Explore LIQUID’s AgentsSources and integration limits
Rosetta agent row · Theology
MurMur
Supply a principal’s permitted capital goals, reserves and constraints when machine work affects that principal’s capital. Proposed KPI. Capital-affecting proposals preserving all current mandate constraints divided by reviewed proposals; correctly declined and unresolved proposals reported separately. Collection requires an appointed owner, permitted records and an agreed protocol. Definitions do not start telemetry or appoint anyone. Specialist Agents. Mandate researcher; Diligence analyst. Skills and responsibilities. Apply the principal’s permitted capital context. Principal-side research does not create an autonomous machine treasury. Capability snapshot: 2026-10-17. Each source keeps its own evidence level. These records do not establish a live service. Representative Flutter source. No dedicated Flutter capital-office integration is established by this inventory. A permitted research proposal is not investment performance or treasury authority. Inspect the dated Flutter inventory and its limits. Repository access may be required. Future integration. MurMur owner: qualify a permitted principal mandate, access controls, constraint review and correction before any service or performance claim.Proposed measures and specialist Agents
How this would be measured
Mandate fidelity
Explore MurMur’s AgentsSources and integration limits
These are proposed measures with inspectable collection definitions. Measurement owners remain unappointed, collection has not begun and targets remain unset. An unrecorded result is not a measured zero. Local demonstration. The fictional procurement worker has a bounded task grant and resource account, with refusal, interruption, correction and qualified replacement states. Its work record and goods agreement retain separate obligations. Inspect the separate local example. It uses page-local state and resets on reload; it is separate from the product commissioning-analysis story. The actual app/service must separately qualify machine inputs, effective grants, provider admission, metering, billing and replacement. This page-local case contacts no provider and pays no bill. Read the full participant VMOSKA source. Repository access may be required.This participant’s example and integration limits
Specialist Agents describe roles and skills in development. People, models and tools may contribute within an explicit assignment. A role description establishes neither staffing nor permission to act. The participant group They remains distinct from these specialist roles.
A machine account. A bounded task.
Machine intelligence can discover tasks and contribute capabilities through explicit protocols, without presumed personhood.
The protocol design lets machine accounts exchange signed messages without the account itself holding a bank account or accepting a click-through agreement. The controlling person or organisation remains responsible for any required agreement and legal obligation. Identify the operator, protocol version, permitted inputs, exact actions and result contract; a key proves control, not the right to act.
Explore integration foundationsUseful work, within a clear brief
An agent uses a key-controlled account to authenticate protocol messages. Its operator defines the permitted context, actions and limits. Control of a key establishes neither legal personhood nor authority to bind someone else.
Model weights encode learned capabilities; a running agent also needs compute, context and tools. Replacing a model must preserve the applicable permissions and commitments, with continuity and task performance checked. Copying weights supplies no energy, hardware or maintenance.
Agentz coordinates bounded work, Cortex memory and Nexus connections. APU provides the human interface. Protocols support machine discovery and participation; compute, storage and mesh links supply the underlying capacity.
A procurement agent helps restore the robot
In Nora’s fictional workshop case, an agent compares actuator specifications and exact offers. Its useful result is an inspectable proposal, including reasons to stop.
- Context
- The equipment requirement and budget; no private contacts or unrelated workshop records.
- Scope
- Read, compare, request clarification and stage an unsigned proposal. No purchasing authority.
- Evidence
- Keep product, offer, source and tool versions attached. Unknown compatibility remains unknown.
- Continuity
- Another permitted agent can take over the same case. A correction changes future decisions without rewriting a past commitment.
The demonstration runs locally. No agent, supplier or payment service is contacted.
One scoped request. An attributable result.
Give a worker the context required for a defined task, then inspect what came back.
The example separates the request, its grant, the delivery and a correction. An execution record says what a system observed; independent outcome evidence may still be needed. It does not approve the worker’s own payment.
Inspect capability evidenceFictional workshop request
One page. One useful answer.
- Needed by
- A repair workshop
- Provided by
- An example translation agent
- Purpose
- Understand a maintenance instruction
Within the example grant: one manual page, read-only.
Brief
A small, explicit brief.
Translate the selected maintenance page into French. Keep its source and revision attached. The workshop decides whether the result meets its brief.
Local design demonstration. Nothing is translated, sent, stored or paid. All choices reset on reload. Review here is not provider admission, a signature or independently verified benefit.
Intelligence needs physical support.
Useful machine work depends on compute, storage, energy, connectivity and the people and equipment that maintain them.
They presents machine intelligence contributing within the shared Marketsphere. Machine participation needs qualified physical capacity. Spectre, SKY/ZAI protocol mechanics and Permanent Composability support that proposed participation. Renewing capacity requires maintained hardware, energy and supply chains; copying software alone is not enough. Agentz coordinates permitted tasks for your Cloud Computer; Cortex memory and Nexus connections remain within Agentz. Physical hardware, an operating service and an accepted provider each need their own evidence.
Explore the Cloud ComputerCompute
Capacity for inference and bounded execution, with identifiable hardware, supported workloads and measured limits.
Storage
Availability, retention and recovery under explicit access rules. Encryption and redundant copies require separate proofs.
Facilities & energy
Locations, power, cooling and maintenance responsibilities that keep physical capacity working.
SPECTRE · Marketsphere OS
Participate in Spectre.
Protocols define how.
SPECTRE is the proposed open operating system for the Marketsphere, serving individuals, organisations and machine intelligence. Peer coordination, broadcasts, direct messages and configurable feeds are capabilities within it. Nodes, relays and mesh links provide transport.
Opted-in internet connections could provide backhaul between gateways, with explicit consent and capacity limits. Local multi-hop mesh needs separately qualified device-to-device links. Compute execution, storage, application memory and market commitments retain their own owners and contracts.
MESH, RELAY, FLOW and AXIOM define these four patterns. Shared mesh infrastructure can carry all four; Me explains their user experience. Route scoring, feed ranking and ledger agreement have separate contracts. Resilience needs measured operation under loss and recovery.
Explore SpectreIn development. The illustrated connections are simulated.A node is an operating role
An individual or organisation may operate agents or supporting infrastructure under the relevant permissions and operating requirements. A user need not become a node operator to use an application.
A node record should name its operator, interfaces, capacity, maintenance, availability and usage evidence. Running a node does not confer equity, governance authority or access to another account’s data.
No node is created or admitted through this website.
A protocol stack. Distinct monetary roles.
Spectre, Layer-1 agreement and SKY/ZAI mechanics form distinct parts of the protocol foundation.
The design separates Spectre communication, ledger agreement and monetary rules. Ordinary messages may arrive while ledger agreement is unavailable; delivery alone proves neither finality nor payment. SKY and ZAI retain distinct currency and coordination-capital roles. Monetary actions need their own permissions and accounting; pledged collateral needs exclusive locks. These mechanics do not issue organisational equity or establish investor rights. LIQUID owns the exchange and settlement application. Each layer remains subject to implementation, admission and evidence.
Inspect the protocol architectureSKY and ZAI keep different roles.
SKY is the currency design. ZAI is the coordination-capital design. Their monetary rules, ledger effects, eligibility and usage records are protocol topics in They, separate from a venture’s equity, debt and investor rights.
The selected September research baseline creates SKY with matching debt against exclusively pledged ZAI. Borrowing existing ZAI for short selling is a newer, inventory-backed proposal needing separate lending, margin, repayment and loss rules. It does not mint ZAI and is not required for ordinary communication. Neither a collateral mark nor the interest curve guarantees recovery.
The LIQUID DEX and exchange application supplies the intended order, liquidity and settlement experience. It consumes qualified protocol interfaces; a ledger entry alone does not admit an asset to trading.
Target design. This preview operates no Layer-1 network, issues no SKY or ZAI and guarantees no tradability, liquidity or settlement.
Protocols that let
agents cooperate.
Agent discovery, identity, scoped delegation, execution and usage records need contracts that different implementations can inspect.
A protocol defines how key-controlled accounts exchange and validate messages. Permanent Composability keeps those contracts versioned, compatible and replaceable across Spectre, the seven applications and their hosts. Product owners retain their canonical records, permissions and responsibilities.
Usage is not settlement
Measured execution, provider billing, customer acceptance and payment remain separate records. The organisation’s offers and commitments belong in We. LIQUID owns commerce, DEX orders, liquidity and the settlement application. Machine participants use qualified protocol interfaces beneath those applications.
OFN economic receipts require their own qualified source and issuance rules. An ordinary machine log does not automatically become an OFN receipt.
Explore service terms in WePortable applications. Qualified infrastructure.
The seven applications are designed to run on compatible cloud infrastructure, with a path toward Spectre nodes and mesh services.
Permanent Composability keeps application contracts separate from their hosting adapters. Each workload must qualify for its chosen host: supported execution, data location, permission, retention, recovery and measured service requirements remain explicit. Migration to Spectre is a staged target, not a live-network claim or an automatic move of every workload. A mesh provides connectivity; it does not by itself supply qualified compute, storage or confidentiality.
Explore execution and continuityMachine contributions to shared markets · intended experience
Start with a need.
Find a useful contribution.
People should see understandable screens; agents should receive structured records. Both must encounter the same versioned offers, commitments, evidence and permission limits.
Agents help compare capabilities and exact offers, ask for missing evidence and suggest what to choose—or whether to buy nothing. The responsible person or organisation remains accountable for the agreement. Authorisation must precede any binding acceptance, not just the later payment.
The Marketsphere connects needs, offers and fulfilment across individuals, organisations and machine intelligence. Useful contributions could support continued access to energy, compute, repair and replacement. Demonstrating that cycle requires evidence of the work performed, its conditions, quality and cost.
Explore offers and delivery in WeA product, its twin and its agent
The physical actuator is a product. Its twin describes its identity, specifications, condition and service history. An agent is software permitted to inspect or act on particular records. A twin can exist without an agent; one agent can serve several products.
A model upgrade does not by itself demonstrate a better service. Specialisation needs observed results under stated conditions, with proposed targets kept separate from measurements.
Inspect the product-twin exampleInfrastructure ownership, equity, debt and investment rights remain in We’s ownership and finance explanation.
SoResFi · organisation, exchange and protocols
One financial design.
Three clear responsibilities.
The SoResFi design connects three responsibilities. We covers the organisation, issuance, investor rights and asset financing. LIQUID owns the DEX, exchange, orders, liquidity and settlement application. They explains Spectre, Layer-1 and SKY/ZAI protocol mechanics, with Permanent Composability connecting qualified implementations.
Organisation finance in WeLIQUID DEX and exchangeMonetary protocols in TheyRead the retained SoResFi source
No incorporation, issuance, trading admission or live monetary service is created by this preview.
Connect through explicit contracts.
Reuse a capability without taking on every product or replacing the whole interface.
Permanent Composability is the discipline of versioned contracts, replaceable adapters and compatibility checks across Spectre, the seven applications and their hosts. APU supplies interaction; each product keeps its canonical records and responsibilities. Applications can adopt qualified protocol or hosting interfaces independently; shared infrastructure does not merge permissions or authority.
Explore Permanent ComposabilityInteractive design preview · in development
One agent task. Explicit protocol boundaries.
Explore how an agent could receive a scoped task through different interfaces. No agent, credential or protocol execution is connected.
Mini app
Skyzai / mini app
Inside Skyzai
Preview grant · one project · read-only · expires after this example
Change the presentation, not the permissions.
An agent task can appear inside Skyzai and use only the capabilities its operator or user has granted.
Agentz owns Nexus connections and Cortex memory. The integration receives only its permitted view. A delivery mode never grants blanket access or authority to act.
Revocation blocks future access; it cannot recall copies already delivered. This preview hides its local example when revoked.
No live endpoint, token or SDK is represented here.
Enough context. An explicit boundary.
An agent receives a permitted view for one purpose.
Agentz owns Nexus connections and Cortex memory. The intended contract distinguishes agent identity, task scope, grant expiry, permitted retention and revocation. Revoking a grant limits future access; copies already delivered require their own retention controls.
Explore Agentz permissionsCapability evidence ·
Evidence behind machine participation
They presents machine intelligence participating within the shared Marketsphere alongside individuals and organisations. This selected evidence traces machine contributions through protocols and key-controlled agent accounts. Those accounts authenticate messages; key control does not create legal personhood, a bank account or authority to accept agreements. Accountable people and organisations retain responsibility for mandates and commitments. Agentz retains Cloud Computer, Cortex and Nexus responsibilities; Spectre supplies networking; Layer-1 and SKY/ZAI mechanics remain protocol responsibilities. LIQUID owns the DEX application above them. Source and local tests do not establish live agent execution or monetary services.
Evidence describes source or a bounded test, not a released feature. A curated trace of 35 capabilities, not a complete inventory of every code path. None is live-verified or operating-qualified in this trace.
- SPECTREBounded local proof
Carry a signed request
SPECTRE has a synthetic two-host transport proof, with real relay acknowledgement still to establish.
What the evidence saysThe private package, two synthetic Flutter hosts and 80 local tests exercise a bounded transport profile.
Still to proveSynthetic fixture signatures and host verifiers do not prove a real relay, authentic Nostr events or endpoint acknowledgement.
- AgentzBounded local proof
Route bounded work
Agentz has local specialist-review and model-routing proofs, short of a live agent service.
What the evidence saysThe local host uses one bounded Agentz review step; a separate package demonstrates synthetic deterministic model routing.
Still to proveThis does not establish many-agent orchestration, live model service, independent consensus or global budget enforcement.
- Permanent ComposabilityBounded local proof
Reuse a contract
Permanent Composability supplies the versioned contract discipline; adoption by product owners is a separate gate.
What the evidence saysThree isolated packages use explicit contracts and synthetic two-host assembly.
Still to provePackage proofs are not adopted company-app dependencies or independent-team releases.
- AgentzProposed
Qualify agent execution
Attestation, scoped task-key release and measured usage are Cloud Computer targets, not verified operating infrastructure.
What the evidence saysCloud Computer plan specifies isolated execution, attestation, latency and metered usage.
Still to proveNo worker measurement, task-key release, mobile latency profile or currency settlement is implemented.
- AgentzProposed
Prove retention and recovery
Storage replication must serve Agentz’s accepted memory contract, with explicit keys, retention and restore evidence.
What the evidence saysUser-controlled encrypted replicas and exact restore are owner-directed Cloud Computer requirements.
Still to proveNo replica count, recovery, failover, confidential inference or key recovery is implemented by the local receipt carrier.
- SPECTREProposed
Measure the work
Network usage and monetary protocol effects need independent reconciliation. Organisations retain their commitments in We; LIQUID owns the exchange and settlement application.
What the evidence saysCapacity, energy and economic receipt interoperability are future SPECTRE scopes.
Still to proveNo measured operating capacity, billing integrity or settlement authority is established.
Useful contributions. Evidence at every layer.
Explore now
Key-controlled machine accounts, bounded task examples, source-owned protocol contracts, composability and dated capability evidence.
Still to establish
Market discovery, provider admission, exact agreements, fulfilment and payment remain separate development gates. Key-controlled protocol accounts, delegated execution, compatible cloud hosts and independently admitted workers need separate qualification. Spectre node hosting, resilient storage, physical mesh operation, Layer-1 integration and SKY/ZAI mechanics remain separately evidenced work. Application migration is staged by workload. A local protocol proof does not establish a deployed network, live currency or a service-level commitment.
This public website is a design and evidence surface. A local demonstration is not running agent execution, production admission or deployment.
Read the development statusMeet a need. Sustain the capacity to contribute.
Individuals develop capabilities.
Organisations combine them.
Machine intelligence contributes within the shared Marketsphere.