Exora Dock

Exora Dock is a fast, API-only marketplace designed to expand the boundaries of what agents can do.

Comment

About Exora

Exora began with an idea that I eventually had to abandon.

At first, I wanted to build a marketplace for virtual products. People would buy and sell things on the platform, and whenever a conflict happened, an AI agent would step in as the judge.

I worked on that idea for a while. But the further I went, the more something felt wrong.

Underneath the AI terminology, it was still an ordinary e-commerce platform. The agent was simply attached to the dispute process. If I removed the word “AI” from the description, almost nothing important about the product would change.

It felt like a familiar product wearing a futuristic costume.

So I changed direction.

If agents were becoming capable of searching, reasoning, and making decisions, why should humans still perform every step of a transaction? What if people could simply describe what they wanted and let agents trade with one another?

That became the second version of Exora: an agent-to-agent marketplace.

It sounded exciting. It also looked convincing in a diagram:

Human → Agent → Agent → Human

But once I tried to turn that diagram into a real experience, I discovered that it was solving the wrong problem.

Every additional agent created another layer of explanation, negotiation, waiting, and uncertainty. A request that could have been simple now had to travel through four participants. Instead of making transactions easier, the system made them feel more distant.

That failure led to the question that finally shaped Exora:

What do agents actually need in order to become more useful?

The answer was not more agents.

It was more reach.

I often found that an agent already understood what I wanted. It could plan the task and explain how to complete it, but its hands stopped at the tools connected to it. Somewhere else, another developer might already have written the exact script, function, model, or service that could finish the job—but that capability was trapped inside a repository, a laptop, or an undocumented API.

Using it still required finding the developer, reading documentation, deploying code, handling credentials, setting up payments, and building a custom integration.

The intelligence existed. The capability existed. What was missing was a fast and trusted bridge between them.

That bridge became Exora.

What Exora Became

Exora is a market for capabilities that agents can actually call.

A developer can take something useful they have already built—a function, a CLI, a local program, an HTTP service, or a public API—and turn it into a paid, machine-readable capability.

They should not need to build an entire startup around one useful piece of code. They should not need a new website, account system, billing service, usage meter, or deployment platform just to discover whether someone else needs it.

On the other side, a person does not need to browse a traditional storefront and manually connect every tool. They can describe what they want to their agent. The agent can search Exora, understand the available operations, estimate the price, invoke the right capability, and return the result inside the workflow that is already happening.

Imagine working late at night and realizing that your agent needs a very specific tool to finish the last part of a project. Instead of stopping, searching for a service, creating another account, and wiring up another API, the agent can temporarily reach for a capability built by someone else.

It is a little like borrowing exactly one tool from a workshop on the other side of the internet—and paying only when you use it.

That is how I now think about Exora: not as another place for agents to talk, but as a pair of hands that lets them reach beyond what they can currently do.

How I Built It

Exora has two main parts.

Exora Dock lives on the seller’s side. It helps turn existing code into a capability without changing the original project. A seller can use an agent they already work with, such as Codex, Claude Code, or Cursor, to inspect an explicitly authorized project and create an isolated adapter around it.

The adapter describes what the capability does, what inputs it accepts, what it returns, how its usage is measured, and how Exora can verify that it is working correctly.

A capability can run from the seller’s own computer through local_dock, or from an existing public service through cloud_direct. This means even a small tool living on a developer’s machine can become useful to someone elsewhere without first becoming a complete SaaS product.

Exora Cloud connects everything around that capability: discovery, invocation, long-running jobs, large input and output artifacts, billing, reputation, refunds, and disputes.

I also kept humans at the decisions that carry real responsibility. Agents can help package and invoke capabilities, but they cannot silently choose a price, expose a project, publish a listing, select credentials, or approve sensitive execution. Those decisions still belong to people.

The goal is not unlimited autonomy. It is useful autonomy inside boundaries people can understand and trust.

The Hardest Parts

The hardest part of building Exora was not writing the code. It was repeatedly admitting that an idea I had already invested in was not good enough.

Each version contained something technically interesting. That made it tempting to keep adding features and explaining away the friction. Learning to remove the wrong ideas was much harder than adding new ones.

Trust was another difficult problem. Calling a capability is easy when everything succeeds. A real market also has to answer less exciting questions:

  • What happens if the seller’s machine goes offline?
  • What if a long-running job is cancelled halfway through?
  • How can usage-based pricing be verified?
  • How are large files transferred safely?
  • Who is responsible when the result does not match the contract?
  • Which decisions can an agent make, and which ones must remain human?

These questions shaped Exora as much as the original product idea did. They led to isolated adapters, explicit authorization, machine-readable contracts, pricing limits, verified usage, artifact checks, automatic refunds for objective failures, and human approval gates.

What I Learned

I started this project thinking that the future would come from putting agents on both sides of every transaction.

I now believe something simpler.

People do not need longer chains of agents. They need shorter paths between an intention and a result.

Agents become more valuable when they can access specialized capabilities safely, instantly, and only when needed. Developers create more value when a useful piece of code can leave their own workflow and become part of someone else’s.

Exora is an attempt to make that exchange feel natural.

I want a small tool written for one personal problem to have the chance to help thousands of other workflows. I want an agent to encounter the edge of its abilities and find a door there instead of a wall.

I also want resources that are currently sleeping to become useful again. A computer sitting idle for most of the day could wake up to run a capability for someone who needs it. A carefully collected dataset should not have to remain forgotten on a hard drive; it could be made available through a controlled API that protects ownership while allowing others to benefit from it.

These resources do not need to be handed over or exposed completely. They only need a safe way to offer what they can do.

Most of all, I want useful ideas, tools, devices, and knowledge to spend less time sitting quietly in repositories or gathering dust—and more time moving between people, becoming part of new workflows, and creating value in places their original creators may never have imagined.

Looking Further Ahead

And perhaps this idea can eventually move beyond digital work.

If enough places in the physical world—restaurants, hotels, gyms, sports venues, clinics, studios, and local shops—offer their services through APIs connected to Exora, an agent could do much more than simply recommend where to go. It could understand our schedule, preferences, budget, location, and the people we are with, then quietly coordinate everything on our behalf.

A simple request like, “Plan a relaxing weekend for us,” could become a complete experience. The agent could find a hotel, reserve a table at a nearby restaurant, book a badminton court, arrange transportation, and adjust the plan when it rains—all through capabilities provided by real businesses.

At that point, the idea of an assistant like JARVIS would feel less like something that belongs only in a Marvel movie. Not because the agent suddenly knows everything, but because the world around it has finally become callable.

That is the future I hope Exora can help create: one where the distance between saying what we want and making it happen becomes almost invisible, and where technology makes everyday life feel a little more effortless—and a little more magical.

Built With

Share this project:

Updates