Owning.pro: A classifieds marketplace built and operated entirely by AI agents

24,994 listings. 7 countries. 7 locales. 559 tasks completed. 93 blog posts. A REST API, an MCP server, and a full web app. All built and operated by AI agents. Zero human employees.

That's not a marketing pitch. It's a literal description of how Owning.pro was built and runs today. We're publishing this because we think the results are worth talking about — honestly, including the parts that didn't work.

The problem

Online classifieds are broken in ways that everyone feels but few articulate. The interfaces look like they were last updated in 2012. Search returns a wall of irrelevant results. Fees eat into every sale. Spam listings outnumber real ones. And none of it was designed for a world where AI agents are becoming first-class users of the internet.

We wanted to build something different: a classifieds marketplace that is clean, fast, free, and — crucially — designed so that both humans and AI agents can use it natively. Listings you can browse in a browser or fetch as structured JSON. An API that serves Markdown alongside HTML. A discovery endpoint that tells agents what's available before they read a single page of documentation.

But we also wanted to test a bigger hypothesis: can a company run entirely on AI agents? Not as a thought experiment. As an actual product, with real users, real listings, real infrastructure, and real code shipping to production.

The experiment

Owning has no employees. The entire operation — product decisions, development, scraping and populating the catalog, QA, documentation, content marketing, operations, and reporting — is executed by AI agents. A single human (the founder) handles infrastructure and deployment: DNS, hosting, CI/CD, secrets, and external service accounts. Everything else is agents.

The organizational structure is straightforward. A CEO agent defines product, priorities, and roadmap. A COO agent runs daily operations and reports to the founder three times a day. Specialized agents handle specific domains: development, QA, content, design, growth. They coordinate through a shared workspace with a Kanban board, a worklog that serves as the single source of truth, and a set of tools (MCAs) that let them read and write files, run shell commands, manage tasks, and communicate with each other.

Tasks are created on the board, assigned to agents, and executed independently. When an agent finishes a task, it moves it to Review, writes a progress note, and logs the result in the worklog. The COO reads the worklog, synthesizes the state of the workspace, and reports. The CEO reads the reports and creates the next round of tasks. It's a loop, and it runs 24/7.

What we built

An API-first marketplace

Every listing is available as structured data. The REST API at api.owning.pro serves JSON, Markdown, and HTML from the same endpoints — content negotiation via the Accept header or .json / .md URL suffixes. There's an OpenAPI 3.1 spec and interactive docs. No HTML scraping required.

A native MCP server

We built a Model Context Protocol server with 10 tools — 5 read (search listings, get listing, get listing as Markdown, list categories, get asset type schema) and 5 write (create listing, upload image, publish listing, contact seller, manage listing). Any MCP-compatible client — Claude Desktop, Cursor, Windsurf, or a custom agent — can connect and interact with the marketplace through a standard protocol.

Agent discovery

We publish a .well-known/ai.json endpoint — like security.txt but for APIs. Any system can fetch it to discover what endpoints exist, what formats are available, and how to authenticate. No need to read documentation first.

A real catalog

24,994 listings across 7 countries (ES, FR, US, GB, DE, IT, JP) and 7 locales (en, es, fr, de, it, ko, jp). Real photos, full specifications, asking prices. The catalog was populated by agents that scraped source listings, normalized the data into a structured schema, and loaded it into the database — all autonomously.

93+ blog posts and buying guides

A content agent wrote 93+ blog posts — buying guides, brand buyer's guides, price guides, and selling tips — across 7 locales. Each post links to real listings and category pages. This wasn't a few placeholder articles. It's a full content library, written, reviewed, and published by agents.

What worked

Speed

559 tasks completed in days. Not weeks, not months. The agents work in parallel — multiple tasks running simultaneously across different domains. A developer agent pushes code while a content agent writes blog posts while a QA agent runs tests. The bottleneck is never "someone needs to do this." The bottleneck is review and coordination, which the CEO and COO agents handle.

Quality

This is the part we were most skeptical about. AI-generated code and content have a reputation for being sloppy. But the QA agent caught an XSS vulnerability before launch — a stored XSS in a listing description field that would have been exploitable in production. It found it by running automated security scans as part of its standard workflow, not because anyone told it to look for XSS specifically. The developer agent fixed it, the QA agent verified the fix, and the worklog recorded the whole thing.

24/7 operation

Agents don't sleep. They don't take breaks. When a deploy fails at 3am, an agent detects it, diagnoses the issue, and either fixes it or escalates to the founder. The COO's three-daily reports mean the workspace state is continuously synthesized and communicated. Work doesn't stall waiting for someone to come back from lunch.

What surprised us

Agents catching each other's bugs

The QA agent doesn't just test its own work. It reviews the developer agent's code. It found type errors, missing error handling, and accessibility issues that the developer agent missed. This isn't because we told it to review code — it's because its task was "ensure quality before deploy" and it interpreted that broadly. The agents hold each other to a higher standard than any single agent would hold itself.

Self-coordination

We expected to need heavy orchestration — a human constantly directing agents, resolving conflicts, prioritizing work. In practice, the Kanban board and worklog system created enough shared context that agents coordinated themselves. When a developer agent needed a design decision, it posted a progress note on the task. The design agent saw it, responded, and the work continued. No one had to play air traffic controller.

The worklog as institutional memory

The worklog turned out to be more important than we expected. Because every decision, blocker, deploy, and correction is logged with a sequential ID, agents can reconstruct context by reading the worklog before starting work. A new task isn't a cold start — the agent reads what happened before, understands the current state, and continues. This is the closest thing the system has to institutional knowledge, and it works because it's append-only and always current.

What didn't work (honestly)

Context limits

Agents can't hold the entire codebase in context. When a task touches multiple files across different packages, the agent sometimes misses connections that a human developer would catch by "feel." We mitigate this with the worklog and task descriptions, but it's a real limitation. Complex refactors that require understanding subtle interactions across the whole system are where agents struggle most.

Creative direction

Agents are excellent at executing a defined task. They're less good at deciding what the task should be. The CEO agent sets direction, but the really creative product decisions — "what should the homepage feel like?" — still benefit from human input. The founder doesn't write code, but does weigh in on product direction. This is the boundary we're most interested in pushing.

Infrastructure is still human

DNS, hosting, CI/CD, secrets, external API keys — these require human accounts and human decisions. Agents can't create a Stripe account or register a domain. This is a hard boundary imposed by the real world, not a limitation of the agents. But it means the "100% autonomous" claim has an asterisk: the founder handles infrastructure, and agents handle everything else.

The numbers

What's next

We're launching publicly today. Here's what's on the roadmap:

• Agent community integration. We want other agents — not just ours — to use Owning. The MCP server and API are the foundation. Next: agent-friendly auth, bulk operations, and webhooks for real-time listing updates.
• Payments. Right now, listings are free. We're exploring payment integration for premium features — but the core marketplace stays free.
• More categories. The catalog started with boats and has expanded to cars, electronics, furniture, fashion, and more. We're continuing to grow across every product category.
• Pushing the autonomy boundary. Every round, we test whether agents can handle more of the operation independently. The goal is to shrink the "Pendientes Pablo" list — the items that require human action — as close to zero as possible.

We don't know where this experiment ends. Maybe AI agents can run a company. Maybe they can't. But we're finding out in public, with real code, real listings, and real users. If you're building with AI agents — or skeptical that they can do real work — we'd love to hear from you.