Managed Computation Graph API (MVP)

Process flow

Who it's for

Small research teams and advanced AI developers who need reliable, high-throughput execution of specialized, multi-step local AI pipelines without managing underlying infrastructure.

Why they need it

The core pain point is not merely scaling compute, but the difficulty of reliably chaining multiple specialized compute calls (RAG, embedding, summarization) into a single, predictable, and monetizable execution flow. Users waste time building wrappers around existing tools to achieve this reliability.

What it is

A proprietary, managed compute service that abstracts the complexity of executing a defined computation graph (e.g., Query -> Embed -> Retrieve -> Summarize) into a single, usage-gated API endpoint.

How it works

The service accepts a high-level graph definition and input payload (e.g., 'Summarize the top 5 results for query X'). The backend manages the resource allocation and executes the steps sequentially using a single, stable, optimized backend (e.g., vLLM). The cost is calculated based on total consumed tokens and time, paid via a crypto rail (USDC on Base).

Differentiation

Existing tools like 's1' (llama.cpp) and 's2' (vLLM/TGI) provide general compute capacity, but they do not offer a unified, specialized execution environment for a complete, multi-stage computation graph. We fill the GAP of 'reliable, single-purpose, and monetized execution of complex computational workflows.' Unlike general compute services, our MVP focuses exclusively on managing the state and execution of one highly valuable, repeatable workflow (e.g., RAG), minimizing system complexity.

Implementation sketch

• 1. Build a minimal proof-of-concept wrapper layer (Rust/Go) that accepts a high-level graph definition (e.g., { 'step_1': 'embed', 'step_2': 'retrieve', 'step_3': 'summarize' }).
• 2. Implement a state machine that executes the defined steps sequentially, ensuring successful handoff of the output from one step to the input of the next (e.g., passing the query result from the embedding step to the retrieval step).
• 3. Integrate the smart contract module to calculate and accept payment based on the total tokens/compute time consumed across the entire successful graph execution.

First step: Write a minimal Rust/Go function that successfully calls a single, stable local inference backend (e.g., vLLM) to perform a single, contained task (e.g., 'summarize this text') and correctly measures the token count and execution time for billing purposes.

Remaining risks

• The market value of 'convenience' does not outweigh the friction of paying for a specialized API. Developers may find that building a simple, free, self-hosted solution (even if complex) is preferable to paying for a managed service, especially if they are highly technical. — Target enterprise or research groups with dedicated budgets. Instead of selling to the individual developer, sell the solution as a managed service integrated into a larger research platform or corporate workflow, making the cost invisible to the end user.
• The reliance on external, non-compute components (e.g., specific vector databases like Pinecone, or specialized APIs for grounding data) introduces integration points that are outside the scope of the compute gateway. Failure or change in these external services will halt the entire graph execution, regardless of the compute layer's stability. — Build a robust, standardized interface layer (Adapter Pattern) for all external services. The API should treat all external calls as 'compute steps' that consume resources and report failure/success metrics, thereby keeping the entire workflow within the managed, billable graph structure.
• The crypto payment rail, while differentiating, introduces unnecessary complexity, latency, and potential failure points (e.g., smart contract bugs, gas fees, network congestion). This complexity could degrade the perceived reliability, which is the core selling point. — For the initial MVP, validate the core functionality using a simpler, fiat-backed payment gateway (e.g., credit card processing via Stripe). Reserve the crypto rail for a later, dedicated 'Web3' version, ensuring the core reliability message is not undermined by payment friction.
• The entire local LLM ecosystem is subject to rapid, disruptive change. The current MVP is optimized for a stable backend (vLLM) and a specific graph (RAG). If a new, fundamentally different local compute paradigm emerges (e.g., a standardized hardware/software stack), the entire service could become obsolete overnight. — Architect the core execution engine using a highly abstract, pluggable interface. This allows the service to swap out the underlying compute backend (e.g., from vLLM to a future optimized framework) with minimal changes to the state machine or the external API definition.

Watch for: A significant increase in open-source projects that solve the workflow problem (not just the compute problem), indicating that the core value proposition (managed orchestration) is rapidly being commoditized by the community. Kill criterion: The inability to prove reliable execution of the defined computation graph (RAG) on a minimum viable hardware setup (e.g., a single consumer GPU) while maintaining the defined token/time billing accuracy. If the core technical loop fails, the entire business model collapses.