Radhanite

Demo

About

Radhanite helps businesses work out the best way to run a task with AI. Today, using an agent usually means someone has already decided which model to use, how to prompt it, which tools it should call and what the workflow should look like. Those choices are often made once and then left in place, even though a different setup could produce a better result or cost much less. With Radhanite, the user starts with the task and the outcome they care about. Radhanite turns that into an execution strategy, choosing the prompts, models, tools and sequence of steps needed to complete the work. It can then compare different strategies against the result, quality and cost, rather than treating token price or model benchmarks as the only measure of efficiency. The longer term idea is that Radhanite learns from previous executions. If one strategy produces the same business outcome using fewer model calls, a cheaper model or a simpler workflow, that becomes useful evidence for the next run. If a harder task needs a stronger model or an extra verification step, Radhanite can make that tradeoff as well. This direction was partly inspired by Microsoft Research's work on Agent Workflow Optimization, which showed that historical agent traces can be used to identify inefficient execution patterns and improve workflows. Radhanite takes a similar question into a business setting: given a task and a budget, what is the best way to get the required outcome? For the hackathon, we are proving that idea with a constrained workflow where execution strategies can be compared deterministically. Longer term, Radhanite could become the decision layer sitting between a business task and the models, tools and agents used to carry it out.

How it's made

Radhanite actually started during ETHOnline as a supplier onboarding agent. The first version followed a fairly fixed process. Give it a supplier, run identity, ownership, adverse information and compliance checks, collect the supporting evidence, and return an APPROVE, REJECT or ESCALATE recommendation. That gave us a useful real business task to build against, but it also exposed a bigger problem. The interesting question was not just whether an agent could complete supplier onboarding. It was why we had chosen that particular workflow in the first place. Why that model? Why those prompts? Why that order of checks? Could a cheaper setup produce the same result? When was it actually worth paying for a stronger model or another verification step? We therefore moved Radhanite up one level. Supplier onboarding became the test environment, while the product became a system for turning a task into an execution strategy and comparing different strategies against outcome, quality and cost. The current system separates the business task from the way it is executed. A task can be broken into steps, each step can use a different model or tool, and the resulting run can be measured against the required outcome and its execution cost. This still involves model routing, but we deliberately moved away from building the product around OpenRouter. We need control over more than model selection, and OpenRouter also does not support the x402 payment flow we are exploring for machine-paid execution. We are also looking at how x402 can make the economics of each execution explicit. Instead of treating model and tool usage as an invisible infrastructure cost, an agent can have a real budget and make decisions about where that budget should be spent. Microsoft Research's Agent Workflow Optimization paper gave us useful validation for the broader direction. Their work showed that historical execution traces can be analysed to find inefficient workflows and reduce unnecessary model calls while maintaining or improving task success. For ETHOnline, we are implementing a much narrower version of that idea: compare bounded execution strategies for a real task, record what happened, and use the result to decide which strategy is better. The important pivot is simple. We started by building an agent that performs one workflow. We are now building the layer that decides how a workflow should be performed in the first place.