Praxis helps businesses embed agents in their operations and serve their own customers.

An agent is AI that can use tools and carry out tasks within an assigned role. We are building a supply-side platform: tools and operating services that let businesses retain control of their operations, brands, and customer relationships.

This plan follows the questions in Sequoia’s business plan guide, from customer problems to products, revenue, and long-term goals. Start with the summary, then follow an online shop adding a customer service agent to its website.

Agents for every business. Praxis helps businesses embed agents in their operations and serve their own customers.

We choose to serve businesses

An agent is AI that can use tools and carry out tasks within an assigned role. We choose to build a supply-side platform: helping businesses that supply goods and services reach their customers directly, while leaving those relationships with the businesses.

Ben Thompson distinguishes platforms from aggregators: platforms help businesses build customer relationships, while demand-side aggregators control access to users. Applying that distinction, Amazon’s shopping destination, Google’s search entry point, and ChatGPT’s personal interface are positions we do not pursue; Shopify, Stripe, and AWS help businesses operate their own services, the direction we choose.

For Praxis, the relationship is platform–business–end customer, or B2B2C: we serve a business, which serves its customers. Stripe Connect offers a useful example of that relationship; the capability Praxis intends to provide is agents.

What businesses need

Imagine an online shop adding a customer service agent to its website. This is an illustrative example, not a customer case: the owner can prepare an agent that answers questions, but still has to handle overnight operation, customer data separation, usage records, failure takeover, and version updates.

Each shop should not have to assemble this from scratch. Businesses and developers need a platform that runs agents over time, paid for through actual resource use; more businesses offering agent services create more need for this layer.

What we provide

The platform design has two parts. Resource services are intended to give developers access to models, sandboxes, search, and compute. Models provide AI capabilities for understanding and generating information, a sandbox is an isolated environment for running tools, and compute is the processing capacity used to execute tasks. Customers connect through a common address and an API key, the credential used to call a service.

The other part is our own agent system, covering building, learning, publishing, running, and operating. Personal Agents act as production employees, helping developers and businesses integrate, build, and operate Service Agents; Service Agents are embedded in the business and serve its customers. Personal Agents are not a mass-market personal assistant product.

We bet on specialization and collaboration: an agent can handle only a limited amount of information at once, so agents should develop specialties and work together. Our agent system runs individuals built through conversation within Praxis and does not accept third-party runtimes. An individual is an agent with its own responsibilities and experience, and a runtime is its execution environment; external agents migrate their prompts, or instructions to the AI, and memory, the information and experience they have retained.

Our three commitments are easy to connect, affordable to use, and dependable in operation: follow the docs or delegate integration to an agent, pay for actual usage with costs falling as scale grows, and keep services running with a record of each call and its cost. These guide what we build; delivered capabilities are listed in Product & traction.

How we can build it and earn revenue

We use AI to build AI: people make decisions, while AI handles much of development, testing, operations, and maintenance. This is our AI-native production method; written rules and repeatable processes reduce the cost of building the platform.

Early revenue comes from the difference between resource selling prices and purchasing costs. Gross margin is the selling price less purchasing or direct operating costs. Model margins and margins on our own compute are resource income; selected services and platform fees are possible later sources of revenue. Tools, documentation, sales, and partners help businesses bring real work onto the platform, rather than creating a separate business competing for personal users.

How advantages accumulate

Useful services earn trust, which brings customers and partnerships; usage and purchasing relationships lower costs, funding both lower customer prices and further development. This reinforcing cycle is called a flywheel: the result of one step helps the next.

In the diagram, “price umbrella” means the room between market prices and purchasing costs for savings and margin; “purchasing premium” means better purchasing terms. “Counter-positioning,” from Helmer’s 7 Powers, means an incumbent’s existing business may discourage it from copying a new approach; “asset accumulation” and “compounding systems” mean accumulated ways of working and continuing improvements through rules, tests, and documentation.

Our view is that selecting and managing suppliers for customers can conflict with large companies’ existing supplier relationships. Agent experience and the team’s working methods also take time to build; a moat is an advantage that makes it hard for competitors to keep taking a business’s customers. These are paths toward an advantage, not an established moat.

Where we are and what comes next

The model service and Praxis App have launch and usage records. We are filling out the platform in the order of agents, sandboxes, and search, then deepening each service. Expansion is based on existing financial data rather than large R&D spending; the funding amount, detailed uses, and forecast appendix remain to be supplied.

The plan starts with what businesses lack between trying an agent and reliably serving customers.

When businesses use agents to serve customers, the hard part is keeping them working reliably over time, beyond a single demonstration.

Customers buy an ongoing service

Imagine a shop owner who has given an agent the product information and checked its answers to common questions. The service still needs to be available when a customer asks about an order late at night; if the answer is wrong, the owner needs to trace what happened and take over.

Our view is that AI has lowered the cost of writing code and made software features easier to copy. Value that is harder to replace is moving toward continuous operation, reliability, and responsibility for results; software remains important, but customers buy the service it supports.

From internal use to customer service

An agent that works well for a business owner can become a repeatable service. An editing agent can work for other creators, just as a shop’s support agent can help its customers.

We expect agents to specialize because context has a capacity limit; context is the information an agent can read during a task. Under this view, an agent should do one specialty well and collaborate with others, rather than one general agent doing the whole business’s work.

After the owner goes offline

During internal trials, the owner can correct the agent at any time. In customer service, the platform must keep running without the owner, identify customers, separate costs, and provide a way to take over when something fails.

Updates must preserve experience and avoid interrupting work. Testing, operations, and long-term reliability require continuing work by a platform and an organization; one AI cannot be expected to handle all of it, and each business should not have to rebuild it.

Why separate tools are not enough

Traditional cloud services mainly provide resources for deploying programs and handling requests. Agents also need to retain work state, use tools, handle uncertain results, and preserve useful experience; model calls often use tokens, units for measuring the information a model processes.

A shop assembling these capabilities pays in three ways: time spent connecting suppliers and building an operating system, effort spent judging supplier quality and costs, and experience lost when work cannot be retained. Servers, model APIs, sandboxes, and search are useful components, but together they are not yet an agent service ready to operate as a business.

The table compares platform responsibilities; it does not claim that programs cannot store state or that agents do not consume compute.

Who encounters the problem first

Independent developers, small and medium-sized businesses, and agent service companies need these capabilities more as they take responsibility for real customers. Model gateways connect several models through one entry point but still require supplier selection and management; hosting platforms and large clouds offer execution tools that businesses must organize into a service.

The gap we see is an agent-centered platform and an organization that handles this work through repeatable processes. The next chapter uses the same shop to show how the service would work.

Praxis connects building, learning, publishing, running, and operating agents so businesses can provide ongoing services within their own operations.

Businesses describe responsibilities and rules through conversation; the platform manages the execution environment and resources. Personal Agents are employees that help build and operate services, while Service Agents are made available to customers; several specialists can collaborate in Praxis App.

The example below follows a shop’s support agent, Xiao An, through the complete process we intend to build. See Product & traction for delivered capabilities; the whole example is not a list of features already launched.

From building to operating

An agent’s lifecycle is the process from its creation to ongoing service. The five steps are build, grow, release, run, and operate; feedback from operations returns to learning and produces a new version.

In the diagram, an “individual” is an agent with its own responsibilities, rules, and experience. A “public agent service” is a published Service Agent offered to customers, not public access to customer data. Private experience can keep changing, while the customer-facing service changes through version releases.

Each difficulty in the problem chapter has a place: platform execution saves assembly time, learning preserves experience, and resource management addresses costs and supplier quality.

One shop’s support agent

Build. The owner tells Xiao An to answer from the shop’s product information and follow its after-sales rules. The platform saves those responsibilities and behavior requirements, called “character” in the existing agent system.

Grow. Xiao An first assists the owner, records corrections, and turns those events into experience, principles, and procedures: what happened, how to make decisions, and which steps to follow. This improvement during work is called online learning; colleagues use Xiao An with its accumulated experience rather than a blank template.

Release. The owner saves a tested version of Xiao An, evaluates it, and then connects it to the shop for customers. Separating learning from customer-facing versions makes the service testable and allows rollback; the version and rules are fixed, not every generated answer.

Run. Customers can ask questions while the owner is resting. The platform keeps Xiao An working, separates customers’ data, runs tools in a controlled environment, and records each step.

Operate. The owner can inspect usage by customer and task and trace execution when a complaint arrives. Improvements are made and evaluated privately before a new release; existing tasks finish on their old version, and new tasks use the new one.

What ongoing operation requires

A runtime is the environment that executes an agent’s tasks and stores its state. It has more to do than make one model call.

Where businesses use it

Praxis App is a tool for building and operating services, with web, desktop, and mobile coverage planned. Businesses can also embed Service Agents in their own products; Personal Agents help them work rather than compete for a mass-market personal entry point.

Future channels can extend to devices with voice interfaces or screens. Wherever the service is used, the business keeps its brand and customer relationships.

How resources connect

Xiao An uses models to answer questions, sandboxes to run tools, and search to find information. The resource goal is a common address and API key, the access credential; within supported scope, customers can retain familiar OpenAI, Anthropic, Google, E2B, and Tavily interfaces and adjust connection settings.

We select models and manage suppliers for customers. Customers choose a model; the platform selects and replaces the supplier behind it, with quality monitoring expected to detect degraded service and compensate customers as promised before they complain. Actual support is defined by the public documentation, and services not yet open are not migration options already available.

Two ways to use Praxis

Hosted. Businesses build agents within Praxis, with the platform responsible for the full process from construction to operation. Our agent system is our own and runs individuals built through conversation in Praxis; it does not plan to accept third-party runtimes, so migrations bring instructions and memory instead.

Resource access. Businesses keep their agents running elsewhere and use only Praxis resource services, with the same model selection and quality commitments. Both forms of use contribute purchasing volume, so improvements in procurement costs can benefit both.

In the diagram, “agent layer” means the system managing responsibilities and experience, “observability and metering” means records and usage measurement, and “version pinning” means keeping a task on a fixed version. “Buyer of record” means selecting and managing suppliers for customers; the legend’s open runtime capabilities do not mean importing third-party runtimes, and the resource-access boundary is the one described above.

Bringing these steps into one platform requires changes in both model capability and development costs. The next chapter explains why those conditions now exist.

Now is the time to build Praxis because models can do useful work, businesses need to turn demonstrations into services, and AI has also lowered the cost of building the platform.

What used to make it costly

Building a cloud platform once required a large engineering team and substantial capital. An agent platform must also bring together execution, memory, sandboxes, identity, and metering, with each part requiring continuing maintenance.

That made a complete platform difficult for a startup to build from scratch. Customers could buy components but still paid the cost of assembling them into a business service.

Development has changed

We use AI as both product and production tool: people set direction and make decisions, while AI handles much of development, testing, operations, and documentation. Building the initial platform and launching the model service are our experience of using this method.

Our view is that this substantially reduces development costs, enabling small teams to build infrastructure that once needed large teams. Our estimate is an order-of-magnitude reduction, or roughly one tenth of the cost; a comparable measurement basis remains to be supplied.

Customer acquisition, sales, and competition for personal users still require substantial money and labor. We therefore turn development efficiency into services for businesses, choosing a supply-side platform rather than competing with model and operating-system companies for the personal entry point.

Business needs have changed too

Models can understand responsibilities, use tools, and carry out sequences of tasks, making conversation a viable way to build agents. Easier prototypes bring businesses to the problem of ongoing operation sooner, making operational reliability more important.

More model choices and price competition at comparable capability levels give supplier selection and management a purpose. Our view is that attention is still concentrated on individual general-purpose agents, leaving room for specialists and their collaboration.

Start with smaller businesses

AWS AgentCore and Anthropic Managed Agents show that running agents has become a platform product. We intend to help smaller businesses through the full process from building to operating, reducing the work of integrating and managing modules themselves.

We start with customers who do not need complex enterprise solutions: independent developers, creator businesses, and small teams. This follows Christensen’s low-end entry approach: lower-cost, simpler products for customers poorly served by existing offerings.

The difference between established platform prices and our purchasing and production costs gives us room to offer savings and operate a business. We believe large providers have commercial reasons to keep serving high-value customers, which gives a small team time; but once developers build deeply into one runtime, migration becomes harder.

Technology can move in a similar direction while serving different customers first. The next chapter explains who those customers are, what they pay for, and where we start.

Praxis’s paying customers are developers, businesses, and service providers using agents in their operations, buying the resources needed to run those services.

Three customer groups

The first group is creators and independent developers. They can use and build specialized agents in Praxis App, turning experience into services for customers; the App should balance professional depth and ease of use, attracting users through work rather than paid advertising.

The second group is small and medium-sized teams and businesses, such as a shop adding support to its website. They can build and run agents on Praxis or keep their own execution environment and use only resource services.

The third group is companies offering agent services to other businesses or customers. Praxis sits upstream, providing execution capabilities and resources; as they serve their customers better, platform usage has room to grow.

All three groups pay for actual usage rather than software licenses. Even a subscription buys resource usage; Personal Agents help these customers produce and operate services, rather than creating a separate mass-market personal assistant business.

What they buy

We focus on model inference, sandboxes, search, runtime compute, and related service fees. Inference is a model processing input and generating output, something that happens repeatedly as an agent works.

Pure software licensing is outside our chosen revenue model. We believe that as features become easier to copy, more value will lie in ongoing services and resources.

Size and adoption

Industry reports help show trends, but their different definitions cannot be added together or treated as revenue Praxis can capture. The table separates market estimates, usage, and survey findings, and identifies evidence still to be supplied.

The number of customers willing to buy agent resource services in our target regions, their budgets, and the resulting addressable spending remain to be supplied.

Start in familiar markets

We start in Chinese-speaking markets in China and Southeast Asia. These markets are close to competitively priced Chinese model supply, have existing resource demand, and are familiar to the team; entering Europe or North America directly would add market-learning and operating costs.

Existing figures supporting this supply argument show Chinese models’ share of OpenRouter tokens rising from below 2% to 46%, attributed to June 2026. The historical snapshot and measurement basis remain to be supplied; a live ranking cannot substitute for historical evidence.

This is not a claim that one market is naturally easier. We first test and improve our methods in a familiar market, then take reusable systems elsewhere; systems should be broadly applicable but still need to fit local business conditions.

Grow with customers’ businesses

Companies providing agent services need execution and resources. We sit upstream and grow with their businesses rather than create all end-customer demand ourselves.

Resource access also has commercial value: Stripe announced an agreement to acquire OpenRouter, with TechCrunch reporting a price above USD 7 billion. An agreement is not a completed transaction; the amount is a media report, not a basis for valuing Praxis.

Products must turn the opportunity into something customers can use. The next chapter separates our existing progress from work still underway.

Praxis has usage records for its model service and Praxis App, and is turning internally used agent capabilities into platform services businesses can integrate.

Product status

The web version of Praxis App has users; the model service has a common address, public catalog, console, and API documentation generated from official specifications. The internal agent system is used in daily work; internal use, available documentation, and a complete stable external service are different stages.

The table separates existing foundations, work underway, and delivery goals. See the developer documentation for current integration scope; the year-end column states goals, not launch announcements.

Usage and revenue so far

As of September 2026, the business record showed more than a thousand registered users, hundreds of additions each month, hundreds of monthly active users, and tens of daily active users. Dozens of paying users prepaid for usage; these historical ranges do not prove the current launch scope of the new platform.

More than ten teams connected directly to the model service, with the number growing weekly. Monthly processing ranged from billions to around ten billion tokens, predominantly on Chinese models chosen by users; tokens measure information processed by models.

In the same period, model revenue exceeded purchasing costs, with a gross margin of roughly 20% that was improving month by month. Here gross margin means revenue after purchasing costs, not company net profit; updated periods, definitions, and detailed records remain to be supplied.

The App uses the platform first

Praxis App is being rebuilt entirely on the cloud services as the platform’s first major customer. The team tests capabilities with real work before offering them to external customers.

The App helps developers and businesses build and operate agent services. Personal Agents assist that work, and Service Agents enter the business’s own operations; App use creates resource usage on the platform.

The method has been used in practice

People leading an AI team built the initial platform. People make decisions and accept results, while AI handles much of development and operations; this supports the cost argument in Why now, although a full cost comparison remains to be supplied.

What we aim to deliver by year end

The end-of-2026 goal is stable model, agent, sandbox, and search services, complete API documentation, and independent sign-up, payment, and first use. Praxis App is planned for web, desktop, and mobile, with specialized agents able to learn, be published, and run through the complete process.

We intend to complete each capability first, then deepen it. The next chapter explains customers’ alternatives and Praxis’s position among them.

Praxis competes with model gateways, agent hosting platforms, and large clouds, choosing supplier management and a complete service to help smaller businesses operate specialized agents.

Our chosen position

We do not train foundation models or compete with model and operating-system companies for the personal user entry point. Using Ben Thompson’s distinction, we choose the platform role that helps suppliers serve customers directly, with businesses retaining their brands, operations, and customer relationships.

Praxis App is a production tool for developers and businesses. Personal Agents help them build, integrate, and operate Service Agents; useful work brings resource usage to the platform, rather than turning the App into a mass-market general assistant.

Specialization and collaboration

Our central belief is that agents will always face limits on how much information they can handle at once. Each agent should focus on a field and work with others, rather than one agent being responsible for everything.

This resembles human specialization: individuals have limited knowledge and attention, yet companies accomplish complex work through collaboration. We believe market attention remains concentrated on individual general agents, so we choose more specific industry tasks in travel, commerce, and their smaller specialties.

Customers’ alternatives

Model gateways. OpenRouter, Vercel AI Gateway, and Cloudflare AI Gateway provide model access and management. Our distinction is to select and manage suppliers for customers and take responsibility for quality; customers need not shop through every supplier themselves, and good service can justify paying for that assurance.

Agent hosting platforms. AgentCore, Managed Agents, and LangGraph Platform provide agent execution and deployment. We focus on joining building, learning, publishing, running, and business operations into one process, reducing what businesses must organize themselves.

Large cloud platforms. They serve broad networks of customers and suppliers. Our view is that selecting and replacing suppliers entirely in customers’ interests can affect their existing relationships and revenue; this is counter-positioning in Helmer’s 7 Powers, where a new approach may damage an incumbent’s existing business and discourage imitation.

These judgments explain how we choose to compete; they do not mean competitors lack related features or cannot change. We target smaller businesses poorly served by the cost and complexity of enterprise solutions, with prices and delivery suited to them.

Reasons to choose Praxis

We intend to combine four things: responsibility for resource quality, service from building through operation, affordability for smaller businesses, and agents that accumulate specialist experience. A cheap API alone does not establish that position.

General agent companies such as Manus may have cost structures close to ours; Risks covers that competition. The next chapter explains how we charge and pass savings on.

Praxis charges customers for actual resource usage, with current revenue coming from the difference between selling prices and purchasing costs.

Charge for resources, initially provide building tools without a separate fee

In the shop example, the support agent calls models, may use a sandbox to run tools, and may consume search and compute. The shop pays for those resources as used, rather than buying a software license or paying for idle resources; a subscription still purchases usage.

The tools for building, managing, publishing, and operating agents are another part of our initial investment. We do not charge separately for that system early on, seeking adoption and trust through convenience, usefulness, and affordability; using Praxis to build an agent does not change the price of the same resource.

Where the margin comes from

Model prices use the model vendor’s official price as a benchmark and stay below it. We buy from upstream suppliers, so better purchasing terms can improve the margin; the markup rate is the same across suppliers, and routing, the choice of supplier for a request, is not driven by that margin.

Recurring operating expenses are counted as compute costs. Small shares are included in resource prices; significant, measurable costs are billed as separate usage-based resources. Margins on our own compute also count as resource income.

We take responsibility for quality

We answer to customers rather than protect suppliers’ business. Customers normally select models without choosing the underlying supplier; we select, monitor, and replace suppliers, and must detect degraded service and compensate customers before they complain, even when we receive supplier rebates.

Large customers can negotiate private, time-limited contracts, allowing the platform to seek terms upstream against committed volume. How quickly upstream price changes reach customers affects retention; price-sensitive customers may leave quickly, others compare over time, and the platform bears the consequences of its pricing choices.

Use savings and partner shares to acquire customers

A shop that stays for the price and experience can recommend the service to other businesses. We turn money otherwise spent on advertising and a sales force into customer savings and partner earnings; referrals receive rewards, distribution earns a share, and customers can become partners.

Revenue sharing means allocating part of a transaction’s proceeds to those who bring customers and usage. Referrers, partners, distributors, and resellers participate in the same system; referrers can take on continuing sales work by introducing customers.

Partners earn under the public partner revenue-sharing plan, Rising Tide. Distributable proceeds come from the purchasing margin after relevant transaction costs: when the available margin is thin it goes to the partner, and when it is thicker it is split equally; the plan page gives the full tiers, and the share is not added to the customer’s price.

This approach aims to bring direct spending on acquiring additional customers close to zero, accepting thin early gross margins and improving purchasing terms through scale. That is an operating goal, not a measured zero acquisition cost; the practical path is in Go-to-market.

Charge for the system after scale

Once scale and trust develop, platform fees, selected services, fees covering building through operation, and shares of Service Agent revenue are ways to earn from the system’s value. We do not set prices or promise launches now; the normal path waits for scale, while Risks retains earlier fees as a response if production costs or purchasing advantages fail.

Costco’s merchandise sales and membership fees illustrate charging for two different forms of value: merchandise prices help customers save, while membership supports the ongoing business. Resource savings and future system fees also play different roles for Praxis, with timing determined by our own operating conditions.

Low prices are easy to copy. The next chapter describes the more lasting advantages we hope to build.

Praxis hopes to defend its position through accumulated customer experience, partnerships, permitted data, and industry working methods, rather than low prices alone.

Advantages take time

A moat is an advantage that makes it hard for competitors to keep taking a business’s customers. As a startup, we cannot claim a secure moat; we can describe the path toward one and the processes already in use.

Some assets cannot be bought instantly. Teaching a shop’s agent to handle real after-sales work takes repeated use, correction, and testing; purchasing trust and partnerships also require a record of delivery.

Dierickx and Cool’s research calls this time compression diseconomies: achieving the same accumulation in less time can cost disproportionately more. Our view is that individual features are easy to copy, while complete working methods and long use may create an advantage.

Four kinds of accumulation

Customers and work experience. Customers arrive for usefulness and suitable prices, build agents, and retain responsibilities, rules, and ways of working on the platform. That gives the next service interaction a stronger starting point.

Purchasing and partnerships. Current purchasing advantages come from relationships already established; growing usage must turn those into volume-based terms. Reliable partnerships and real purchasing volume take time and cannot be gained by copying code.

Permitted data. Domain and professional data can become platform assets when use complies with law and agreed purposes, with customers able to choose. Terms must explain the use; data passing through the platform does not mean unrestricted rights to use it.

Industry working methods. How travel or commerce agents divide tasks, cooperate, and apply effective rules must be tested in real business. We believe that each of these four assets can accumulate faster as it grows.

Specialization is the premise

If general AI can handle every business without specialization, these domain assets will offer little protection. We believe limited context will drive specialization, making a field’s customer experience, relationships, data, and working methods worth sustained investment.

This is the same judgment as in Competition: choosing specialization means relying on its continuing usefulness for future advantage.

Keep each improvement

Rules, tests, and documentation let a correction help future work instead of solving only the immediate problem. Marketing and sales also become repeatable processes, while the human-led AI team improves with use; this continuing benefit from each improvement is what we mean by “compounding systems.”

Managing purchasing for customers, taking quality responsibility, passing savings on, building specialist services, and organizing production with AI depend on one another. We believe copying one choice alone is insufficient; competitors may need to change other parts of their business to achieve similar results.

Purchasing terms and counter-positioning may develop earlier than other advantages; counter-positioning means existing business can discourage a competitor from copying a new approach. Large clouds must consider supplier relationships, and gateways that change customer-directed supplier selection may lose existing pass-through usage; these remain competitive judgments to test in the market.

Accumulation starts with continued customer use. The next chapter explains how customers find Praxis and connect their businesses.

Praxis starts with existing users, executable documentation, and partners to serve developers and businesses that are not yet deeply committed to another platform.

Who comes first

We start with creators, independent developers, and small teams in Chinese-speaking markets in China and Southeast Asia. We first serve those needing an affordable option who have not tied their work to one runtime, rather than actively pursuing deeply committed customers.

The sequence is existing Praxis App users, developers arriving through documentation, and businesses introduced by partners. We validate the approach in one market before taking reusable methods to another.

A conversion rate is the proportion of people who move from one step to the next. Each stage has its own measure; registration counts do not tell the whole story.

Documentation is an entry point

A shop owner may ask their agent to “add customer support to my website” before studying our homepage. An agent reads information, uses tools, and performs tasks for a person; it will use the docs to judge whether Praxis can do the job and then integrate it for the owner.

This is documentation as a control plane: instructions through which agents operate the platform, beyond a product introduction. In this form of integration, the first reader is an agent. Customer acquisition for a supply-side platform therefore shifts from the homepage to the docs; readable, executable documentation makes successful integration possible.

The docs must bring together prerequisites, integration steps, expected results, and recovery instructions. Compatible resource services let customers adjust connection settings from their own environment without first moving the entire agent or learning the whole system; supported interfaces and specific addresses are in the developer documentation.

Successful integration gives customers a reason to stay

For the shop, success means support is working on its website, not that an agent has read many pages. Each unclear step adds another chance of failure; retention depends on whether an agent can complete a short enough path successfully on the first attempt.

A common address and API key reduce connection information to manage, while errors must explain the cause and next action. Incorrect docs can lead agents to repeat mistakes and can be collected and spread elsewhere, so documentation accuracy directly affects product usability.

From use to operating a service

The owner first uses agents in Praxis App, then builds a service with their own information and rules, and publishes a tested version for customers. Work creates a reason for each step from user to builder to service publisher.

The App should balance professional depth and ease of use; Personal Agents handle building, integration, and operations within it. This serves business production rather than turning Personal Agents into another mass-market personal entry point.

Customers and partners bring customers

Owners can refer other businesses, and developers can become partners who help businesses integrate. Referrals receive rewards, distribution earns a share, and referrers can keep introducing customers; customers, partners, distributors, and resellers participate through the same system.

We share some proceeds with those who bring actual usage, replacing an advertising budget and an ever-growing sales force. The next chapter describes who builds these processes and how the team works.

Praxis is built by its founder leading an AI team, with collaborators and advisers in operations, product, and research.

Team and company

We entered the agent field in March 2025 and used AI to build AI from the start. People set direction and make decisions, while AI performs much of the work; this is what the plan means by an AI-native company.

Deepractice is the company and Praxis is the platform. Its entities are 南京深度实践人工智能科技有限公司 in Nanjing and Praxis Global Limited in Hong Kong; the earlier platform domain is deepraxis.ai, with product and company information in the company section.

How experience supports the work

Engineering. Founder Jiang Shan worked as a software engineer at WeBank across testing, operations, and development, experiencing large internet systems from construction through operation. That helps us judge what remains between a prototype and a lasting service.

Product. The PromptX open-source project uses the MIT license and had more than 3,700 GitHub stars as of September 2026; stars record community interest, not paying customers. Earlier records also include AtomGit G-Star graduation certification and selection for City University of Hong Kong’s HK Tech 300 seed fund in December 2025.

The paper PromptX: A Cognitive Agent Platform with Long-term Memory, developed with City University of Hong Kong, appears in the WWW 2026 Demo acceptance list. Open source tested product adoption and built community relationships that continue to introduce users to Praxis; moving the platform to cloud services brought further interest in promotion.

Business. The founder previously operated internet travel and internet solutions businesses, including a company with annual profit in the millions of RMB and a team of around 50, alongside several failed ventures. Hands-on experience in marketing, sales, operations, financing, and finance exposed the cost of labor-intensive delivery; see the Xinhua Daily Jiao Huidian profile.

Our starting advantages

Understanding agents supports the product approach, engineering experience supports platform construction, and AI working methods have been used in the initial build. Open-source relationships provide a start for long-term advantages and customer acquisition, while the paper exposes the method to outside examination.

These support continued work rather than guarantee success. We still need time and scale; the work financing would support is in Milestones & financials.

People judge, AI works

People specify what to do, what comes first, and what counts as done. AI performs much of development, testing, maintenance, documentation, and operations, serving as both product and production tool.

People and AI follow the same public working rules: how to start work, demonstrate completion, hand it over, and recognize when to stop for human judgment. Personal Agents act as employees in this work, helping build and operate customer-facing services.

Make corrections repeatable

Every correction should leave a rule, procedure, or memory rather than depend on one person remembering it. Tests handle what can be checked automatically, and programs handle repeatable work.

We want the team to work better than last month because it has retained reusable methods, not just because individuals are more practiced. This is also a source of cost improvement in Why now.

Do not depend on exhaustion

People have limits on time and attention. We do not build the business on anyone remaining overloaded or on critical judgment staying with one person.

Work that can be expressed as rules and verified goes into repeatable processes first; people handle the judgment that remains. Work can then grow without requiring the same growth in personal effort.

Use our own products first

Praxis App is our daily development tool, and the cloud services first handle our real work. We encounter and bear the cost of poor usability or unreliable operation ourselves.

The initial platform build and model service launch are existing records of this approach in use. The next chapter examines where these judgments and methods could fail.

Praxis’s main risks are that low costs and specialization do not hold, or that purchasing, service quality, or cash flow cannot sustain the business.

Risks guide where we put effort

We prioritize resource purchasing, supplier management, production costs, and specialist experience. Our judgment is that getting these foundations right enables a supply-side platform to grow; they require ongoing monitoring, investment, and expansion, not a one-time build.

Eight risks need active mitigation. We also accept costs that follow from choosing not to buy advertising, build a sales force, or compete for the personal entry point.

Cost structure fails

Chapters 3, 7, and 10 share a premise: AI working methods and purchasing advantages support thin margins and no early platform fee.

The trigger is production costs no longer falling as methods improve, or the purchasing advantage disappearing.

The response is continuing improvement rather than a one-time cost cut; if either premise fails, charging platform fees earlier remains an option. This is the exception to waiting for scale under normal conditions.

Purchasing advantage does not last

Current terms in the business model and moat depend on time-limited contracts and relationships.

The trigger is an expired contract not being renewed, or purchasing continuing to rely on one channel.

The response is to keep adding channels and gradually move from relationship-based terms to terms supported by purchasing volume.

Supplier quality or reliability declines

The solution and business model require the platform to manage suppliers for customers and take responsibility for quality.

The trigger is a deviation in quality probes: programs that regularly check latency, error rates, and whether output meets expectations.

The response is ongoing monitoring, prompt supplier replacement, and proactive compensation rather than waiting for complaints.

Specialization is the wrong bet

Competition and the moat assume that focusing on a field and accumulating experience improve service.

The trigger is specialist agents being no better than general agents, with no continuing accumulation of industry working methods.

If this judgment fails, resource services and the complete process from building to operation still have value, but domain experience provides less protection.

A peer with similar costs enters

Companies such as Manus, discussed in Competition, may have production costs close to ours.

The trigger is a move into specialization and collaboration at lower prices; we cannot assume we will win on price.

The response is to rely on accumulated industry experience and proactive compensation commitments rather than continuing to compete on price alone.

Data use is noncompliant

The value of data in the business model and moat depends on compliance and agreed purposes.

The trigger is a difference between stated purposes and actual use.

The response is clear disclosure and customer choice. Our tradeoff is that customers whose strong privacy requirements do not fit this public cloud service are not suitable customers for it; compliance is a condition for data to be an asset, not an expense to omit.

Key people become overloaded

The team’s method still relies on human judgment, which can easily concentrate in a few people in a small team.

The trigger is critical judgment remaining concentrated in one person.

The response is to put repeatable decisions into rules and verification processes, keeping people’s workloads sustainable rather than depending on exhaustion.

Cash flow comes under pressure

The financial arrangements must manage the timing difference between customer prepayments and supplier payments.

The trigger is a widening gap that increases funding pressure.

Once the business holds funds in transit, it should manage them under applicable financial rules, set risk limits, and avoid putting those funds into positions that expose them to additional losses.

Costs we choose to accept

Without advertising or a sales force, customer growth may be slower than that of heavily funded competitors, and the brand must build through recommendations. Passing savings on means thin early profit; not competing for personal users or building a general assistant also means forgoing those opportunities.

Once core services and operating processes work well and the team has capacity, we can give acquisition more attention and investment. The focus here is business customer growth; serving businesses in their own operations remains our direction.

The next chapter turns these choices into near-term delivery and uses of funds.

Praxis aims to complete four services and the full onboarding process by the end of 2026, with funding mainly supporting people who lead the work, procurement, business development, compute, and channels.

Year-end delivery criteria

The model service has a launch record, Praxis App has users, and sign-up, payment, and calls have been run through; see Product & traction. The next stage is judged by the criteria below, not just whether a feature appears in an interface.

The order remains to complete each capability, then deepen it.

The following year

In 2027, we intend to improve purchasing channels, supplier management, and compute, addressing the cost, procurement, and quality issues in Risks. We also intend to validate agent specialization and cooperation in one or two industries, such as travel and commerce, producing reusable working methods.

Partner referral, revenue-sharing, and distribution mechanisms should also launch as an alternative to expansion through advertising and a sales force. These are directions; detailed stage targets remain to be defined.

Spending and uses of financing

The existing plan records monthly spending in the tens of thousands of RMB, roughly divided between people, AI production subscriptions, and platform operating costs. Operating costs paid by the company during internal testing enter resource prices as external usage opens; the expense remains, but the company no longer subsidizes all of it.

Current revenue comes from resource purchasing margins, not software licenses; we expect scale to improve purchasing terms and gross margins. Expansion is extrapolated from existing income and costs rather than relying on large R&D investment.

Financing first supports human work: setting direction, designing structure, leading construction, procurement, and business development. Compute and purchasing channels come next; the funding amount, itemized uses, forecast assumptions, and financial appendix remain to be supplied.

These investments serve one long-term goal: agents for every business.

In five years, we hope specialized agents in every industry will be working continuously on Praxis, so that every business can serve its own customers with agents.

Agents for every business.

Turn experience into a service

Having agents act as employees, salespeople, or service staff has required businesses to build and maintain a complete system. We intend to lower that barrier so small businesses can also use AI in daily operations.

One person’s experience can become an agent’s reusable capability, then combine with other specialists to provide a customer-facing service. Personal Agents help build and operate it; Service Agents enter the business’s own operations.

Three commitments

Easy to connect. Follow the documentation, or give the job to your agent, and integrate with your website and business successfully on the first attempt. Use an existing agent or describe the responsibilities, information, and rules you need, leaving technical work such as the runtime to AI and the platform.

Affordable to use. Pay for actual usage, not idle resources, with lower costs as scale grows. The platform selects and manages model suppliers and keeps turning better purchasing terms into prices customers can obtain.

Dependable in operation. Continuous execution, failure takeover, and a record of every call and its cost should support services for real customers. These three commitments guide product development and operations; actual delivery status is in Product & traction.

Businesses own their services

Travel will have its agents, commerce its own, with finer specializations inside each industry. Operators publish capabilities they have found useful and tested, allowing agents to collaborate and accumulate professional experience.

Businesses retain their operations, brands, and customer relationships; Praxis helps them build and run services. That is the role of a supply-side platform: helping businesses serve their customers rather than making them dependent suppliers to a personal entry point.

Back to everyday business

Our belief remains that as software features become easier to copy, more value lies in ongoing service, with agents providing a new way to deliver it. We aim to build a place where agents can exist, learn, and serve customers.

From a shop helping one customer to specialist services working together across an industry, the test is whether the three commitments hold. That is how the positioning in the summary becomes part of a business’s daily work.