Dapta

Inspiration

We have worked inside large organizations and repeatedly saw the same problem: a promising AI experiment becomes an expensive production workflow.

At first, sending a long prompt to a frontier model seems inexpensive. Enterprise AI, however, is not used once. The same support policy, extraction schema, compliance checklist, examples, and formatting instructions may be processed thousands, and eventually millions, of times.

As AI adoption increases, that repeated reasoning becomes repeated spending.

Many business tasks are narrow and predictable:

Extract the same fields from every contract.
Route support requests into the same queues.
Convert receipts into the same expense schema.
Clean recurring datasets using the same rules.
Apply the same internal policy to every document.

General-purpose models are remarkable, but repeatedly paying a generalist to relearn the same procedure is wasteful. The instructions consume tokens again, the model processes the same examples again, and the business pays for the same reasoning again.

We started Dapta by asking:

What if an organization could pay for the reasoning once, then turn it into a small, reusable specialist?

Dapta does not try to replace frontier models. They remain essential for unfamiliar, ambiguous, and genuinely difficult work. Dapta exists to stop companies from paying frontier-model prices for work that has become routine.

What it does

Dapta is an autonomous skill-to-model factory.

A user describes a recurring business workflow in a normal conversation. Dapta determines whether an existing specialist can handle it, whether a new specialist should be created, or whether the request should remain with a general-purpose model.

Every request first passes through JEV, our intelligent router. JEV evaluates whether the work is stable, repeated, testable, and suitable for specialization. If important requirements are missing, Dapta asks follow-up questions before starting paid work.

When a new specialist is justified, Dapta:

Converts the request into a precise skill contract.
Defines the required inputs, outputs, rules, exceptions, and schema.
Creates deterministic validators and integration evidence.
Builds separate training, development, frozen test, and out-of-distribution datasets.
Checks the data for duplicates, leakage, invalid labels, and schema errors.
Trains a lightweight LoRA adapter on a shared Qwen base model.
Evaluates Qwen Base, Qwen with the complete Skill, and Qwen LoRA on the same held-out cases.
Measures speed, token consumption, cost, and accuracy.
Publishes successful adapters to a reusable specialist registry.
Routes future matching requests to the trained specialist.

A LoRA adapter is a small set of learned weights that specializes a shared model without retraining or duplicating the entire model. This allows one Qwen base model to support a growing collection of business-specific specialists.

Our frozen NDA benchmark included 83 documents. The measured field-level F1 scores were:

$$ F1_{\mathrm{Base}} = 57.58\% $$

$$ F1_{\mathrm{Base+Skill}} = 61.28\% $$

$$ F1_{\mathrm{LoRA}} = 70.75\% $$

Exact-form accuracy improved from 6.02% with the base model to 33.73% with the LoRA adapter.

The product keeps quality and economics together. A cheaper model is not valuable if it is inaccurate, and a more accurate model is difficult to operationalize if its cost cannot be understood.

Dapta therefore shows outputs and measurements side by side. Users can review speed, tokens, dollars, and accuracy instead of relying on a vague claim that fine-tuning is better.

Through our Fetch.ai and ASI integration, these capabilities are also accessible beyond Dapta's own interface. Users can discover and interact with Dapta's registered agent through the ASI ecosystem, connecting natural-language requests to specialized AI workflows.

How we built it

We built Dapta as four connected systems: a conversational interface, an intelligent routing layer, an autonomous adapter factory, and a shared model runtime.

The frontend is built with React and TypeScript and deployed through Base44. Instead of asking users to configure a machine-learning pipeline, Dapta presents the experience as a conversation.

JEV routes every request. It can select an existing adapter, recommend creating a new one, ask for missing information, or determine that a general model remains the better option.

When a new adapter is approved, Kimi K3 acts as the Skill Architect. It converts the user's description into a structured contract containing the input format, output schema, rules, exceptions, and evaluation criteria.

Devin acts as the Skill Integration Engineer. It receives a scoped task and creates supporting integration evidence such as validators, schemas, fixtures, and tests. Devin cannot approve its own work, alter the frozen test set, or decide whether an adapter passes.

Dapta then creates and validates the dataset. Training, development, frozen test, and out-of-distribution examples remain separated. The final test set is hashed and frozen before model improvement begins.

The backend is built with Python and FastAPI. It manages routing, comparison runs, factory jobs, adapter metadata, usage accounting, and the complete training state machine.

We use Qwen3-VL-8B-Instruct as the shared base model and QLoRA through PyTorch and PEFT to create lightweight adapters. Training and inference run on RunPod GPU infrastructure.

Our inference layer uses vLLM to serve Qwen and dynamically load LoRA adapters. When training requires GPU memory, Dapta safely suspends the inference workload, starts a bounded training worker, restores inference afterward, and re-registers the available adapters.

Every build has time and spending limits. Users can stop a build at any active stage. Dapta prevents later stages from starting, terminates the owned worker or Devin session, preserves completed artifacts, restores Qwen inference, and confirms cleanup before reporting that the build has stopped.

Completed adapters are versioned and stored through Hugging Face. SQLite maintains the authoritative job, benchmark, and usage ledger, while Supabase stores sanitized snapshots for the hosted product.

We use OpenRouter to compare the specialist against configured frontier models. The same input is sent to each approach, and Dapta records its output, latency, tokens, cost, and quality score.

Fetch.ai / ASI Integration

Dapta integrates with Fetch.ai's Agentverse and ASI using the uAgents framework, Agent Chat Protocol v0.3.0, and Mailbox.

Our registered agent, dapta-lora-factory (@dapta-lahacks), allows users to discover and execute specialized AI workflows directly through ASI.

This connects Dapta's reusable AI capabilities with a broader agent ecosystem, enabling real task execution through natural-language interactions without requiring users to interact directly with the underlying model infrastructure.

The integration includes:

Agentverse: Registration and discovery of Dapta's agent within the Fetch.ai ecosystem.
uAgents: The framework used to implement the agent and its communication capabilities.
Agent Chat Protocol v0.3.0: Structured conversational communication between ASI and Dapta.
Mailbox: Message delivery infrastructure connecting the registered agent to the ecosystem.

Registered Agent: dapta-lora-factory

Agentverse Handle: @dapta-lahacks

ASI Agent: https://asi1.ai/ai/agent1qduksj2e80jpszjpp86c9rtvq3l7rl99gh0nnyvuxqs6w2gplgkzjazmmsv

This integration represents an important part of our vision: specialized AI capabilities should not remain isolated inside individual applications. Once a workflow has been converted into a reusable specialist, other agents and users should be able to discover and invoke it without rebuilding the underlying intelligence.

Observability and Autonomous Repair

Sentry provides end-to-end observability across the browser, controller, background workers, provider calls, training, evaluation, and publishing stages. We use tracing, logs, AI monitoring, and privacy-masked Session Replay.

Sentry also supports Dapta's repair decisions. The system distinguishes among:

A genuine model-quality failure.
An incomplete or truncated evaluation.
A dataset or schema problem.
A software failure.
An infrastructure failure.

A truncated evaluation should be rerun, not retrained. A software failure can become a scoped Devin repair task. Retraining is recommended only when the infrastructure and evaluation are valid but the adapter still misses its quality threshold.

Challenges we ran into

One of our largest challenges was making an autonomous system safe when things do not go according to plan.

A factory run crosses several external services and long-running processes. Provider calls may be slow, Devin sessions can remain active, GPU workers must be terminated carefully, and a browser refresh cannot be allowed to abandon paid work.

We implemented durable state transitions, idempotent operations, bounded execution, process-ownership checks, cancellation checkpoints, cleanup retries, and inference restoration. A stopped build remains visibly in a "stopping safely" state until cleanup is actually confirmed.

Another challenge was sharing one GPU between inference and training. The base model and the training process compete for GPU memory. Dapta had to suspend vLLM safely, run the owned training worker, handle cancellation or failure, restore the model, and dynamically reload the adapters.

Evaluation was equally difficult. A successful training process does not prove that the resulting model is useful. We needed to separate development feedback from final evaluation, prevent cross-split leakage, freeze test data, and distinguish a wrong answer from an output that was simply truncated before it could be scored.

We also learned how difficult it is to compare different models honestly. Providers use different tokenizers, pricing structures, latency profiles, and output formats. We avoided collapsing everything into a single "best model" claim. Dapta presents speed, tokens, cost, and accuracy independently and preserves unavailable measurements as unavailable.

Finally, we had to make a complex technical system understandable. The underlying architecture involves routers, agents, datasets, validators, GPU workers, model servers, registries, and distributed traces. The user should not have to understand those concepts to create a specialist. Designing the product as a conversation helped us hide the machinery without hiding the evidence.

Accomplishments that we're proud of

We are proud that Dapta became more than a fine-tuning script. It is a complete system for deciding when a reusable specialist should exist, creating it, proving that it works, and safely operating it afterward.

Dapta can:

Route every request through JEV.
Discover and reuse existing adapters.
Determine whether a workflow is suitable for specialization.
Ask follow-up questions before beginning paid work.
Convert an informal request into a testable skill contract.
Generate and validate separated datasets.
Detect duplicates and evaluation leakage.
Freeze and hash the final test set.
Enforce training time and cost limits.
Train and publish lightweight LoRA adapters.
Dynamically serve multiple adapters through vLLM.
Compare Qwen Base, Qwen with Skill, Qwen LoRA, and frontier models.
Preserve speed, token, cost, and quality evidence.
Trace the complete lifecycle through Sentry.
Distinguish retraining from evaluation or infrastructure repair.
Safely stop a build without destroying earlier work.
Expose specialized workflows through a registered Fetch.ai Agentverse agent.
Support natural-language agent communication through ASI using uAgents and Agent Chat Protocol v0.3.0.

We are particularly proud of the NDA benchmark result. The LoRA adapter improved field-level F1 from 57.58% with Qwen Base and 61.28% with Qwen and the complete Skill to 70.75%.

Another important accomplishment was integrating Dapta into the Fetch.ai and ASI ecosystem. By registering dapta-lora-factory on Agentverse, we made our model factory discoverable through an external agent network, demonstrating how specialized AI workflows can become reusable services rather than remain confined to a single application.

We are also proud of the product experience. The model factory feels like a conversation rather than a collection of infrastructure controls, while still exposing the measurements and decisions needed to trust the outcome.

What we learned

The biggest lesson was that training is only one part of creating a useful specialist.

The harder questions are:

Should this workflow be specialized at all?
What does a correct result look like?
Where should the training truth come from?
How do we prevent evaluation leakage?
What happens when a provider fails halfway through?
Does a bad score require retraining or only evaluation repair?
How do we safely share limited GPU infrastructure?
At what usage volume does the adapter recover its creation cost?
How do we communicate the result to someone who is not an ML engineer?

We learned that deterministic validation is extremely valuable. Whenever an answer can be checked using a schema, calculation, or business rule, code should establish the truth rather than another model.

We also learned that observability can be more than a debugging tool. A distributed trace can reveal whether a failure occurred during routing, integration, validation, training, evaluation, publishing, or rendering.