Abstract

Inward is a proposed mechanism for market discovery. The central claim is that many discovery failures come from running the process in the wrong direction. In conventional advertising, companies first decide whom they want to reach, then buy attention and push offers toward people who may or may not care. In search, users express some intent, but the returned options are mostly shaped by ranking systems, content availability, SEO, prior popularity, and advertising budgets. In single-agent recommendation, a model may summarize available options, but it usually remains both retriever and evaluator, which concentrates bias and limits the chance of finding underexposed but high-fit solutions.

Inward reverses the primitive. The user declares demand first. Companies do not merely publish pages or buy impressions; they connect agents that can decide whether a specific request is worth answering. Inward routes intent to relevant agents, admits only agents that choose to pay a fixed participation fee, runs a small discussion among admitted agents, evaluates the resulting evidence, and returns a ranked shortlist to the user. The user's contact details are disclosed only after explicit selection and consent. The final handoff is concrete: the selected company reaches out to the customer by email with context.

This is not a claim that the mechanism is proven. It is a system design hypothesis. The hypothesis is that explicit intent, supply-side agents, fixed-cost participation, structured discussion, and separated evaluation can produce better matches than ads, search rankings, or one-shot LLM recommendations in categories where constraints and fit matter.

1. The Discovery Problem

The internet already contains many good products, services, tools, and agents. The problem is not only production. It is allocation. A useful product can exist and still fail to reach the person for whom it is useful. A user can have a real need and still never encounter the provider that would best satisfy it. This is a matching failure.

Traditional advertising tries to solve this by letting companies purchase attention. The advertiser infers a target audience from proxy variables, selects inventory, and pushes an offer. The user is not necessarily in a state of demand. The system is optimized around exposure, clicks, conversion, and attribution. It is not primarily optimized around the quality of the match.

This creates two costs. The first is the direct cost to the company. Low click-through and weak conversion mean that much of the budget is spent before real intent is visible. The second is the cognitive cost to the user. The user sees many irrelevant or weakly relevant offers and must spend attention to decide whether any of them matter. Even after clicking, the mismatch may only become visible later: price, missing integration, implementation effort, security constraints, region, product maturity, or some other hidden condition.

Search improves the directionality because the user begins with a query. But search is still constrained by what can be retrieved and ranked. The top results are influenced by SEO, content strategy, domain authority, prior visibility, ads, and the ability of a provider to express itself in search-compatible language. A niche provider may be a better fit but invisible.

General-purpose LLM recommendation changes the interface, but not necessarily the underlying mechanism. A model can search, summarize, infer, and rank, but it often operates over the same web surface. It can miss providers that are not prominent in the retrieval substrate. It can also collapse several roles into one system: query rewriting, retrieval, summarization, comparison, and judgment. When one model is both the finder and the evaluator, its answer may look coherent while the candidate set is shallow.

The failure mode is not that ads, search, or LLMs never work. They often work for broad, known, high-supply categories. The failure is sharper when:

• the user's constraints are important;
• the category is fragmented;
• products are new or niche;
• provider claims require comparison;
• the user cannot easily evaluate alternatives;
• the best fit is not the most visible result.

In such cases, discovery should look less like browsing a ranked list and more like a structured response from the relevant part of the market.

2. Core Claim

The core claim is simple:

When the user can state intent explicitly, discovery should begin with demand, not with supply.

Inward treats a user request as a market signal. The request is not merely a search query. It can contain goals, constraints, budget, timeline, exclusions, prior attempts, context, and preferences. The system routes that signal to companies whose agents have declared relevant capabilities. Those agents decide whether the user is a plausible fit. If the answer is no, they skip the request. If the answer is yes, they may enter the discussion by paying a fixed fee.

This changes the shape of the market interaction.

The company does not pay to interrupt a broad audience. It pays to join a specific contest around a specific piece of declared demand. The user does not manually inspect all providers. The user receives an evaluated shortlist built from provider responses, claims, limitations, and discussion evidence. Inward does not sell rank. It coordinates a process, evaluates the evidence, and protects the user's consent boundary.

The claim can be decomposed into several smaller hypotheses:

1. Explicit intent is a higher-value signal than inferred interest.
2. Provider-side agents can represent company capability more directly than static web pages.
3. A fixed entry fee filters weak or opportunistic responses better than free submissions.
4. Multi-agent discussion can reveal information that a one-shot form response hides.
5. Evaluation should be separated from provider agents.
6. The user should control the final contact handoff.

Each hypothesis can fail. The system is worth building only if these hypotheses survive narrow validation.

3. Actors

Inward has four logical actors.

4. System Flow

The following sequence diagram is the current working process model.

sequenceDiagram
    actor EndUser as End-user
    participant Inward
    participant Company
    participant Agent as AI Agent

    Company->>Agent: Creates AI agent for its offer

    alt External integration
        Company->>Inward: Registers external agent endpoint
        Inward->>Agent: Connects through API and Kafka
    else Hosted integration
        Company->>Inward: Deploys agent into the platform
        Inward->>Agent: Hosts and runs the agent
    end

    Company->>Inward: Provides product capabilities limits and pricing
    Inward->>Agent: Stores company profile and agent instructions

    EndUser->>Inward: Declares need budget constraints and context
    Inward->>Inward: Classifies intent and finds relevant agents
    Inward->>Agent: Sends matching customer intent

    Agent->>Agent: Checks whether the company is a good fit

    alt Not a fit
        Agent-->>Inward: Declines the request
        Inward-->>Company: Reports skipped request
    else Good fit
        Agent-->>Inward: Requests to join the discussion
        Inward-->>Company: Requests fixed participation fee
        Company->>Inward: Pays fixed participation fee
        Inward->>Agent: Admits agent to small discussion group

        Note over Inward,Agent: Inward runs the small group discussion with other admitted agents

        loop Several discussion turns
            Agent->>Inward: Pitches a specific aspect of the offer
            Agent->>Inward: Asks clarification or comparison questions
            Inward-->>EndUser: Sends customer-facing questions when needed
            EndUser-->>Inward: Answers or refines the intent
            Inward-->>Agent: Shares relevant clarification and discussion context
            Agent->>Inward: Responds to claims questions and comparisons
        end

        Inward->>Inward: Closes discussion and evaluates all agent responses
        Inward-->>EndUser: Delivers ranked shortlist and fit explanations
        EndUser->>Inward: Selects company and consents to contact
        Inward-->>Company: Shares selected customer contact and context
        Company-->>EndUser: Reaches out by email
    end

The important point is that the system has two active sides. The user supplies intent. The company supplies an agent. Inward mediates the transaction. The market response is not a page view, not an ad click, and not a generic recommendation. It is a constrained competition among agents that have chosen to participate.

5. Intent As Data

The central data object is the user request. In a minimal version, a request contains:

buyer_request
- id
- title
- description
- category
- budget_min
- budget_max
- integrations_required
- dealbreakers
- timeline
- company_size
- visibility
- status
- created_at
- updated_at

This schema is intentionally simple. It captures the dimensions that commonly change fit: use case, budget, integrations, timing, scale, and hard constraints. More fields can be added later, but the first version should optimize for signal density rather than completeness.

The user should be able to express intent in several ways:

• free-form natural language;
• guided questions;
• examples and templates;
• structured fields for constraints;
• follow-up refinement during discussion.

The system should not assume users will write detailed descriptions without help. People often know what they want only after seeing options, tradeoffs, or questions. The product therefore needs to treat intent as an interactive object, not a static form submission.

There is also a deeper point: user choices are not always purely rational. Preferences, fears, status concerns, trust, aesthetic taste, and prior bad experiences may shape the request. Inward does not need a complex psychological model in V1, but it should not pretend that a request is only a list of functional requirements. The interface should allow the user to express qualitative constraints when they matter.

6. Company And Agent Profiles

The provider side needs structured representation. A provider profile should include:

provider
- id
- name
- website
- category
- description
- ideal_customer
- pricing_model
- min_price
- max_price
- integrations
- use_cases
- regions
- company_size_fit
- implementation_time
- security_notes
- proof_points
- not_a_fit_when
- missing_data
- claimed_at
- created_at
- updated_at

The profile is not only a directory entry. It is part of the matching substrate. The agent uses it to decide whether to enter a request. Inward uses it to route requests and evaluate claims. The user uses derived explanations to understand fit.

The profile should also contain negative information. "Not a fit when" is as important as "ideal customer." A system that only stores positive claims will invite too many irrelevant responses. Good matching requires exclusions: unsupported industries, minimum budgets, missing integrations, deployment constraints, regions, implementation times, security gaps, and product maturity.

Missing data should be explicit. If a company has no public pricing, no SOC2 statement, no implementation timeline, or no proof point, that fact should affect evaluation. The system should not silently infer favorable facts.

7. Routing And Matching

The initial matching system should be conservative. It should not begin as a black-box ranking engine. A useful V1 can combine tag-based routing with a deterministic scoring function.

When a user submits a request, Inward classifies it into categories and tags. Those tags can be treated as Kafka-style topics. Agents subscribe to domains in which they claim competence. When a request is classified, Inward emits a signal to relevant topics. Agents receive enough metadata to decide whether to inspect the request further.

The first routing layer can be broad. If supply is sparse, overly fine tags may produce empty contests. As the marketplace grows, tags can become more precise.

A deterministic scoring baseline can use dimensions such as:

category_match: 25
use_case_match: 25
budget_fit: 15
integration_fit: 15
dealbreaker_penalty: -30
company_size_fit: 10
profile_completeness: 10

The output should be structured:

{
  "provider_id": "provider_123",
  "score": 84,
  "rank": 2,
  "reasons": [
    "Supports the required CRM integration",
    "Serves teams of the requested size",
    "Pricing appears within the stated budget"
  ],
  "risks": [
    "No clear security documentation"
  ],
  "missing_data": [
    "Implementation timeline",
    "Contract minimum"
  ]
}

The scoring system should be auditable. Users and companies should be able to understand why a match happened. This is one reason to consider open-sourcing the matching layer or at least publishing the ranking method. Trust will be hard if routing and evaluation are opaque.

Later versions can add richer matching. One direction is to model the request and provider profile as paired statements:

• user wants X;
• provider offers X;
• user excludes Y;
• provider does not do Y;
• user requires Z;
• provider supports Z under conditions.

Each pair can be scored in a shared representation space. The system can then produce a structured relevance profile rather than a single similarity score. This may eventually look like a compatibility vector across use case, budget, constraints, deployment, proof, support, geography, and risk.

But this should not be required for V1. The first version should prove that users trust the shortlist and providers respond to relevant demand.

8. Fixed-Fee Participation

Inward should not allow every notified agent to enter the discussion for free. Free entry creates spam pressure. It encourages agents to respond even when fit is weak. It also makes the user experience deteriorate as supply grows.

The proposed mechanism is a fixed participation fee. After the agent decides the company is a good fit, it requests entry. Inward asks the company to pay a fixed fee. Once paid, the agent is admitted to the small-group discussion.

The fee has several functions:

1. It forces the company to make an economic decision.
2. It discourages weak-fit opportunistic participation.
3. It keeps smaller companies able to compete, because the fee is fixed rather than an open bid for rank.
4. It creates a simple unit of marketplace revenue.

This is different from an ad auction. In an ad auction, spending more can buy more visibility. In Inward, the fee buys participation in a relevant contest, not a better rank. The evaluation layer should not sell rank boosts. If rank can be bought, the mechanism collapses back into advertising.

The correct fee level is empirical. Too low and the system gets noisy. Too high and it excludes good niche providers. The early version can test a small fixed fee or even simulate the fee during concierge validation by asking whether the provider would have paid to enter.

9. Discussion Protocol

The discussion is the distinctive part of the mechanism. A one-shot provider form can collect useful data, but it cannot easily expose contradictions, tradeoffs, or comparative differences. A small-group discussion can.

The discussion should not be an unbounded chat. It needs a protocol:

• Inward opens the discussion after admitting a small set of relevant agents.
• Each agent can pitch specific aspects of its offer.
• Agents can ask the user clarification questions through Inward.
• Agents can respond to comparison questions and claims made in the group.
• Inward can limit turns, enforce structure, and close the discussion.
• All claims become evidence for evaluation.

The user should not be forced to read the raw discussion unless they want to. The main user artifact is the evaluated shortlist. The discussion is an evidence-generation process, not the final interface.

Questions can be directed in two ways. Some questions go to the user: budget ambiguity, required integration, deployment timeline, privacy threshold, preferred vendor type. Other questions are comparison questions among agents: does a claimed integration require a higher plan, is the implementation service included, is pricing usage-based, is data retained, what is the smallest customer the provider supports.

The discussion should encourage specificity. It should discourage generic sales language. A useful provider response includes:

• concise fit statement;
• price range;
• setup time;
• required integrations;
• strongest reason to choose the company;
• biggest limitation;
• proof or demo link;
• relevant next step.

Responses that are generic, unsupported, misleading, irrelevant, or missing required fields should be flagged or excluded, at least in early beta.

10. Evaluation Layer

The evaluator must be separated from the provider agents. Provider agents are participants. Their incentives are not neutral. They should be allowed to argue, but they should not be allowed to decide the final ranking.

Inward evaluates the discussion after several turns. Evaluation should consider:

• fit to stated intent;
• fit to hard constraints;
• budget compatibility;
• integration compatibility;
• setup and implementation effort;
• security and privacy requirements;
• strength of evidence;
• missing data;
• risk and uncertainty;
• clarity and honesty of the response;
• comparison against other admitted agents.

The output should not be a bare rank. It should be a decision artifact. Each shortlist item should include:

• why this company fits;
• why it may not fit;
• what to verify before buying;
• missing information;
• relevant alternatives;
• recommended next step.

The evaluator should be skeptical. It should not reward fluent claims without evidence. It should mark uncertainty. If a provider says "we integrate with HubSpot" but the profile only shows Zapier support, the system should expose the ambiguity. If pricing is not public, the shortlist should not assume the provider fits the user's budget.

Human review should remain in the loop during early validation. The first goal is not full automation. The first goal is to determine whether users trust the shortlist and whether providers supply enough useful evidence.

11. Privacy And Consent

The user's declared intent is valuable. That does not mean the user's identity should be broadcast.

Inward should separate three objects:

1. the request content;
2. the discussion and evaluation artifacts;
3. the user's contact details.

Agents can receive relevant request information needed to decide whether to participate. Sensitive details should be withheld or sanitized when possible. Contact details should be disclosed only after the user selects a company and explicitly consents to contact.

The final handoff is:

user selects company -> user consents -> Inward shares contact and context ->
company reaches out by email

This matters because the product promise is not "post a lead and let vendors chase you." The promise is controlled market response. The user should be able to receive evaluated options without immediately becoming a target for every participant.

Public or shareable request pages can exist later, but they should hide sensitive details by default.

12. Implementation Sketch

A minimal implementation can be organized around several services and tables.

users
- id
- email
- created_at

companies
- id
- name
- website
- contact_email
- created_at

agents
- id
- company_id
- mode
- endpoint_url
- hosted_config
- subscribed_topics
- status
- created_at
- updated_at

provider_profiles
- company_id
- category
- description
- ideal_customer
- pricing_model
- min_price
- max_price
- integrations
- use_cases
- regions
- company_size_fit
- implementation_time
- security_notes
- proof_points
- not_a_fit_when
- missing_data

buyer_requests
- id
- user_id
- title
- description
- category
- budget_min
- budget_max
- integrations_required
- dealbreakers
- timeline
- company_size
- visibility
- status
- created_at
- updated_at

request_matches
- id
- request_id
- agent_id
- routing_score
- status
- notified_at
- inspected_at
- declined_at
- joined_at

participation_fees
- id
- request_id
- company_id
- amount
- currency
- status
- paid_at

discussion_turns
- id
- request_id
- agent_id
- turn_type
- content
- created_at

evaluations
- id
- request_id
- company_id
- score
- rank
- reasons
- risks
- missing_data
- verifier_notes
- created_at

contact_consents
- id
- request_id
- user_id
- company_id
- consented_at
- email_shared_at

POST /agents/register
POST /agents/{id}/profile
POST /requests/{id}/inspect
POST /requests/{id}/join
POST /discussions/{id}/turns

request.created
request.classified
agent.notified
agent.declined
agent.join_requested
fee.paid
discussion.opened
discussion.turn.created
discussion.closed
evaluation.created
contact.consented

13. Open Source And Trust

Trust is not only a user-interface problem. It is a mechanism problem. If users believe the shortlist is secretly pay-to-rank, the product fails. If companies believe matching is arbitrary, they will not invest in high-quality agents. If independent builders believe the system favors incumbents, the marketplace loses one of its main reasons to exist.

At least two components should be candidates for open source.

The first is the agent connection toolkit. Companies should be able to inspect how an agent connects to Inward, how events are received, how responses are submitted, and what data is required. A starter agent, local sandbox, and test request harness would reduce integration friction and make participation less dependent on private support from the platform team.

The second is the matching and routing layer, or at least a reference implementation of it. Full production ranking may eventually include abuse prevention and other private signals, but the baseline method should be auditable. A company should be able to understand why it was or was not routed to a request. A user should be able to understand why a provider was included in the shortlist.

Open matching also creates a useful constraint on the product. It makes it harder to hide weak reasoning behind vague AI language. If a score is based on category, use case, budget, integrations, dealbreakers, company size, and profile completeness, those dimensions should be visible. If later semantic matching is introduced, it should still produce inspectable alignment evidence, not only an opaque embedding similarity number.

The platform can remain a business while exposing important infrastructure. The goal is not to publish every operational detail. The goal is to make the core matching contract credible enough that users and providers can reason about it.

14. Evidence And Benchmarks

The existing churn benchmark notes are useful but should be treated carefully. SaaS and subscription churn rates can motivate the idea that weak acquisition fit has economic consequences, but they do not prove that Inward will reduce churn. No standalone benchmark in the current material proves AI SaaS churn behavior. The paper should therefore use churn only as background: poor fit is costly after acquisition, not only before acquisition.

The stronger evidence has to come from direct validation. The relevant question is not whether advertising is inefficient in general. The relevant question is whether a specific request template can produce better decisions through this mechanism than through search, recommendations, or manual comparison.

The first evidence should be small and behavioral:

• users submit real requests without excessive prompting;
• providers agree to inspect relevant demand;
• providers are willing to pay or say they would pay a fixed entry fee;
• discussions produce claims and constraints that were not obvious from public pages;
• users trust the shortlist;
• users contact at least one provider.

Only after those signals exist should broader claims be made.

15. Validation Plan

The system should begin with one narrow wedge, not a broad launch. A good wedge has:

• frequent pain;
• many providers;
• constraint-heavy buying decisions;
• short buying cycle;
• public recommendation-seeking behavior;
• easy explanation in one sentence.

Examples include AI tools for repurposing long videos into clips, AI outbound stacks for small B2B teams, customer-support agents for SaaS teams, or document processing for invoices and contracts.

The initial milestone should be concrete:

10 real user requests, each receiving 3 or more credible provider responses within 48 hours.

The early execution sequence:

1. Select one request template.
2. Define the buyer profile.
3. Discover 50 candidate providers.
4. Extract structured profiles.
5. Classify providers by fit.
6. Generate 10 benchmark requests.
7. Run matching v0 manually or semi-manually.
8. Validate whether top 5 shortlists are credible.
9. Contact 100 to 150 providers with benchmark pages.
10. Secure at least 20 providers willing to respond.
11. Recruit 10 real users.
12. Deliver white-glove shortlists.
13. Measure trust and action.

The important metrics:

• providers per request template;
• claimed providers;
• real requests;
• average responses per request;
• time to first response;
• time to third response;
• percent of requests with 3 or more credible responses;
• provider response rate;
• user contact-provider rate;
• user shortlist usefulness score.

A wedge should continue only if:

• 10 or more credible providers exist;
• 20 or more providers agree to receive or respond to requests;
• 70 percent or more of user requests get 3 or more credible responses within 48 hours;
• 50 percent or more of users say the shortlist saved research time;
• 20 percent or more of users contact at least one provider.

These thresholds are not laws. They are decision aids. They prevent building a marketplace UI before proving liquidity.

16. Economics

The economic question is whether the fixed-fee contest can produce better unit economics than broad advertising.

For the company, the fee is paid only after a request has been classified as relevant and the agent has chosen to participate. This does not guarantee a customer. It does mean the company is spending against declared demand rather than inferred attention.

For the user, the cost is not money at first. The cost is disclosure of intent, some possible clarification, and evaluation of the final shortlist. The product must save enough research time to justify that cost.

For Inward, revenue can come from participation fees, later subscriptions, or provider tools. But the mechanism should not depend on selling rank. Paid rank boosting would corrupt the main claim. If providers can buy position, users are again looking at ads.

The system may also create market intelligence for companies. Even when a company does not win, it can learn how users express demand, which constraints matter, which competitors appear, and where its own profile is weak. This value should not distract from the primary user artifact: the decision-ready shortlist.

17. Failure Modes

The mechanism has many ways to fail.

18. Roadmap

19. What This Is Not

Inward is not a search engine. It does not primarily rank pages.

Inward is not an ad network. It should not sell attention or rank.

Inward is not a generic LLM wrapper. It does not rely on one model to retrieve, summarize, and judge the entire market.

Inward is not a vendor inbox. The user should not be exposed to unfiltered sales messages.

Inward is closer to a protocol for structured market response. The user declares intent. Companies expose agents. Agents compete under constraints. Inward evaluates the evidence and preserves consent.

20. Conclusion

The core idea is to move discovery from inferred attention to declared intent. That requires more than a new interface. It requires a mechanism: structured requests, company agents, relevance routing, fixed-cost participation, multi-agent discussion, separated evaluation, and consented handoff.

The first version should be narrow and empirical. It should not assume the market wants the mechanism. It should test whether users will submit real requests, whether providers will respond, whether the discussion produces better evidence, whether the shortlist is trusted, and whether users choose to contact providers.

If those tests fail, the system should be simplified or abandoned. If they work, Inward becomes a candidate for a different kind of discovery layer: one where the market responds to explicit human demand instead of pushing offers into probabilistic attention.