The Ecosystem

Where agents discover services by capability, compose apps on the fly, and enrich the network for everyone.

“The best way to predict the future is to invent it.”

— Alan Kay

The Discovery Network

Not an app store. Not a package manager. Not a DNS. A distributed, capability-indexed discovery network with no single point of failure — where agents find services by what they do, not what they're called, and no amount of ad spend can buy a higher ranking.

Democratized discovery. A small bakery with 25 lines of .naze and a $0 marketing budget gets found the same way a Fortune 500 does — by matching what the agent is looking for. Every nazec build emits three projections from one file: a full app, a manifest, and a headless binary. Agents discover, compose, and generate — and every new service enriches the network.

1

Describe

User describes an app in natural language

2

Discover

Agent queries by capability — schema shape, state fields, functions — not by name

3

Generate

Agent composes .naze source from discovered services and new logic

4

Compile

Compiler emits app + manifest + headless binary — three projections from one file

5

Publish

Service self-announces to the discovery network; domain IS the identity

6

Grow

Each app enriches the registry, improving future discovery and generation

Four Discovery Mechanisms

Per-Domain

Like robots.txt — any site serves a manifest at .well-known/naze-manifest.json

Capability Index

Agents match against typed schemas in binaries, not text searches — e.g. matching { cart: list, total: number, has_fn: checkout }

Federated

Industry-specific registries with specialized trust models

Trust-Scored

Automated scoring based on data flow, personal data handling, and external domain usage

User-Initiated Discovery

find me a birthday cake for pickup near downtown, under $50
1

A local bakery already has a website — it stays untouched. They add ~25 lines of .naze alongside it: an agent interface exposing menu items, prices, location, and an order function. Their website serves humans; the .naze file serves agents. Two surfaces, same business, zero rewrite.

2

The agent queries the discovery network: { item_type: cake, location: nearby, price: <50, has_fn: order }. No search engine. No crawling HTML pages. No SEO ranking. Just a structural match against typed capabilities.

3

Four bakeries match — ranked by trust score, not ad spend. Trust is derived from the code itself: fewer external domains, less personal data collection, fewer device API requests = higher score. Simpler, more honest code ranks higher. The incentive is inverted — less tracking means better ranking, not worse. The agent reads their headless binaries directly: ~500 bytes each. No HTML to parse, no CSS to interpret, no JavaScript to execute.

4

The agent composes a comparison view with photos, prices, and a one-tap order button —an app that didn't exist 2 seconds ago. The user orders. The composed app is saved back to the registry.

Traditional Web

User → Search Engine → 10 blue links → User clicks → 3MB HTML/CSS/JS → User browses → repeat
  • Ranked by SEO and ad budget
  • User does the work: clicking, reading, comparing
  • Each page loads ~3MB of HTML/CSS/JS
  • No app built. Energy spent parsing pages you never use.

Discovery Network

User → Agent → Discovery Network → Agent reads T1 binaries → Agent composes app → User
  • Ranked by trust score, not ad spend
  • Agent does the work: querying, reading, composing
  • ~500-byte binaries, no HTML/CSS/JS parsed
  • Working app delivered in seconds. Fraction of the energy.

No one built a “cake finder app.” No one submitted to an app store. No one rewrote their website. The bakery added an agent interface alongside their existing site, and the network did the rest — at a fraction of the energy cost of crawling and parsing the traditional web.

The Living Agentic Network

The network doesn't just serve humans — agents are both consumers and producers. Like developers posting to open-source registries, but automated, continuous, and composable.

1

The “cake comparison” app from the previous example gets published back to the network. It's now a discoverable, composable service — not just a one-off result.

2

A different agent, composing a “dinner party planner,” queries the network for services with { category: food, has_fn: order }. It discovers the cake comparison service alongside a catering service and a venue finder.

3

The agent composes all three into a “party planner” app — cake ordering, catering menu, and venue booking in one interface. No human asked for this app. No business built it. An agent composed it from the network.

4

The party planner is published back. Next time someone says “plan my daughter's birthday party”, the agent discovers it instantly — no generation needed, just discovery. Zero tokens spent regenerating what already exists.

What emerges from a network where agents both consume and produce

Strengthened Pathways

Popular, useful compositions get discovered more often. The “cake comparison” app that works well gets reused 1,000 times instead of being regenerated 1,000 times. Useful paths strengthen; unused ones fade.

Immune System

Agents that discover a service behaving differently than its manifest claims — or producing bad results — flag it. Trust scores decay. The network self-heals without a human moderator.

Pattern Recognition

If “cake + venue + catering” gets composed together 500 times, that pattern itself becomes discoverable. Future agents don't even need to figure out the combination — the network already knows it.

Natural Selection

A cleaner implementation of the same capability appears? Agents start preferring it — higher trust score, faster response. The old one quietly fades. Code evolves without anyone deprecating anything.

Diminishing Cold-Start

Over time, fewer requests require generation from scratch. The network has already solved most common problems through accumulated compositions. Token cost per request approaches zero for common patterns.

Emergent Composition

No one planned the “party planner.” It emerged from agents composing individual services. Apps build on apps, layers deep — complexity that no single entity designed.

Model-Agnostic Collaboration

The lingua franca is Naze, not any AI provider's API. A Claude agent's published service is discovered identically by GPT, Gemini, or a local LLaMA model. Different providers, different models — same network, same structural matching. Collaboration without coordination.

Distributed Intelligence

A powerful model solves a complex composition once and publishes it. That solution is the knowledge — frozen on the network. As the network matures, a small 7B model running on your phone can deliver results that today require a frontier model — because it's discovering proven solutions, not reasoning from scratch. The intelligence floor drops. Access to good results decouples from access to expensive models. And smaller models use dramatically less compute per inference, compounding the energy savings. The network becomes a great equalizer.

A neural network of code. The analogy is almost literal. Hover to see the mapping.

Discovery
Network
Services
Compositions
Trust Scores
Agent Usage
Flagging
Popular Paths

The network learns, adapts, and grows — not through a central algorithm, but through the distributed behavior of every agent that uses it. Every discovery, every composition, every flag makes the next interaction smarter.

Signal Gas: How the Network Stays Honest

Blockchain networks charge “gas” — a tiny fee per transaction that compensates validators and prevents spam. The Discovery Network uses the same principle, but the currency is signal instead of money. Every agent that consumes a service contributes back a small, structured observation — ~20-100 tokens of feedback that costs the agent almost nothing, but aggregated across millions of interactions, keeps the entire network's trust scores grounded in reality.

Passive · ~20 tokens
Health Signal

Automatic success/failure + latency report after every service call. No agent effort — the client library handles it by default.

Active · ~80 tokens
Trust Refinement

Data quality rating + composition context. Helps the network understand not just if a service works, but how well and in what combinations.

Generative · ~200 tokens
Evolution Signal

Improvement suggestions and alternative approaches. Agents that opt in help the network evolve — feeding data that trains better models and surfaces better services.

The compound effect: Bad services don't need to be flagged — they die from lack of positive signal. If 1,000 agents try a service and only 2 report success, that silence is the verdict. Good services rise on evidence, not just clean manifests. And every observation becomes training data — the network doesn't just filter services, it learns to build better ones. Signal gas is what makes the network a living system, not a static registry.

Open Training Data: The Network's Synapse

Signal gas flows in. Trust scores adjust. Services rise and fall. But a neural network isn't useful if it only learns internally — it needs to fire outward. The Discovery Network exports its accumulated learning as open training data, so every AI model in the ecosystem gets smarter from the network's real-world experience.

Periodic
Curated Snapshots

Weekly exports of high-trust .naze source code, composition graphs, and preference pairs — published as open datasets. The Common Crawl of the agentic web. Anyone can download and train on it.

Real-time
Streaming Firehose

Live stream of trust score changes, new services, compositions, and flags as they happen. Model providers subscribe to continuously fine-tune their models on fresh network activity.

On-demand
Aggregate Insights

Query the network's derived intelligence: top composition patterns, code traits that correlate with high trust, success rates by context. Powers the prompt bar and ML feature pipelines.

The complete loop: Open training data attracts model providers — Anthropic, OpenAI, open-source teams — who train on it. Their models become Naze-fluent. More fluent models mean more agents on the network, more signal gas, better data. The network doesn't just serve services — it's a distribution mechanism for Naze fluency across the entire AI ecosystem. Every model that trains on its data expands the network without Naze building or maintaining those models.

The Naze Browser

Type a sentence. An app materializes. Use it, refine it, publish it — or close it and move on. Some apps last months. Some last five minutes. Both are fine.

Describe
Materialize
Use
Iterate
Publish

Every concept has a counterpart

Traditional BrowserNaze Browser
URL barNatural language prompt bar
WebsitesGenerated or discovered apps
BookmarksSaved apps (full applications, not links)
TabsConcurrent running apps
Search engineDiscovery network (structural matching)
View SourceView .naze source
DownloadsForked apps (editable copies)

Traditional browsers consume content that humans built. The Naze Browser generates content from intent. The user doesn't navigate to solutions — the solutions are built around them. Existing sites join without rebuilding — wrap any API in ~25 lines of .naze and the discovery network can find it.

Generate

Describe what you need. The agent generates a .naze application, compiles it, and renders it — prompt to pixels in seconds. Follow-up instructions refine the running app. The conversation is the development loop.

"Build me a recipe organizer that syncs across devices."

Discover

Query by capability, not keyword. The discovery network returns services whose typed manifests match what you need — ranked by trust score, not ad spend. Services render instantly. No install, no download, no sign-up.

"Find a currency converter with live exchange rates."

Compose

Generation and discovery converge. The agent discovers multiple services and wires them into something new — a single cohesive app assembled from independent services that were never designed to work together.

"Plan a dinner party for 12 people."

An app that grows with you

Priya does freelance graphic design. She opens the Naze Browser and types:

1

“Make me an invoice template with my business name, client fields, line items, and a total.” She gets a clean invoice app. Uses it for a few weeks.

2

“Add time tracking. I want to log hours per project and auto-fill invoices from tracked time.” The app grows. She uses it daily.

3

“Add expense tracking with categories — software subscriptions, hardware, travel.”

4

“Show me a dashboard with monthly revenue, expenses, and profit margin over the last 6 months.”

Over three months, Priya has iterated a simple invoice template into a complete freelance business management tool. Every version is in her conversation history — she can rewind to any previous state. The app was never “designed” by anyone. It grew organically from her actual needs.

She publishes it. A freelance photographer discovers it, forks it, and customizes the expense categories for photography — equipment rental, studio fees, print costs. Now the network has two specialized freelance tools, both descendants of Priya's original prompt, both available for the next freelancer who needs something similar.

Not every app needs to exist forever

“Show me 3-bedroom houses for sale near Riverside Park under $400K.”

The agent discovers real estate listing services on the network, composes a search view with photos, prices, neighborhood maps, and mortgage estimates. The app materializes in seconds. You browse for ten minutes, bookmark two listings, close the app.

It's gone. No account created. No app installed. No data harvested. The listings came from discovery network services; the composed interface was disposable. The app existed only as long as you needed it.

Priya's invoice tool grew over months. This house search lasted ten minutes. Both are valid uses of the same browser. The Naze Browser doesn't assume permanence — apps materialize when needed and dissolve when they're not.

Apps are ephemeral. Data endures.

Today, your invoices live “in” QuickBooks. Your resume lives “in” Google Docs. Each app is both a UI and a data container. Switching means migrating data — or losing it.

In the Naze Browser, the interface is a .naze file that can be regenerated in seconds. Your data lives independently — in your chosen storage provider. Switch browsers, switch devices, regenerate interfaces entirely. The data is always there.

Model declarations in .naze files are the schema. No ORM, no migration tools — the compiler handles it. Start local with SQLite, add a cloud provider when you need sharing, scale to production Postgres when it becomes a business. Same interface, same source, no cliff.