Dilip Bagrecha once worked on international payments at Royal Bank of Scotland. As a SWIFT architect, he had little room for the sort of answer that sounds reassuring until someone’s money disappears into the qualification. A payment system had to work. The inconvenient cases counted, too. It was an education in the difference between software that performs well in a demonstration and software that deserves responsibility.
Today, as co-founder and CEO of Wishtree Technologies, Bagrecha spends his time in an industry considerably more fond of demonstrations. AI can write, retrieve, reason and act. It can also make the wrong action look beautifully composed. His interest lies in getting useful systems into everyday business, where the audience has orders to fulfil and accounts to reconcile. Applause is pleasant; a working process is considerably easier to renew.
His career has included Infosys, RBS and UBS. Wishtree, established in 2010, became the setting for his own approach to engineering services. Its work now spans product development, cloud, data and AI. Across those changes, a familiar concern keeps appearing: how a promising idea behaves after people begin depending on it.
Before those professional chapters, he attended Sarvajanik College of Engineering & Technology from 1999 to 2003. His listed activities included debate, general knowledge quizzes and theatre. It is a pleasingly varied set of pursuits for someone who would spend a career explaining complicated systems to people with different priorities. His profile also lists four languages: Marwari, English, Gujarati and Hindi. The details broaden a portrait often occupied by architecture and deployment. There was room in his education for an argument, a question and a stage, alongside the technical work that would become his profession.
Wishtree established
Writing on cloud resilience
Building with AI agents
An outage, and a refusal to panic
In March 2017, an Amazon Web Services outage prompted clients to ask Bagrecha whether they should rethink their cloud architecture. His answer was measured. A failure affecting a service in one region did not justify announcing that the entire cloud, or the internet, had fallen over. He wanted the discussion to stay close to what had actually failed.
He drew attention to the awkward detail that the dashboard intended to report service problems had itself become unavailable. That is an engineer’s sort of irony: even the messenger needs a contingency plan. His response put the emphasis on understanding the incident, learning from it and improving the underlying practices. A dramatic diagnosis would have made a more exciting headline. It would have been less useful to a client deciding what to do next.
The episode gives his present arguments about AI some history. He was thinking publicly about resilience long before the current enthusiasm for agents. His subject has changed its vocabulary. The question of what happens when an apparently dependable system encounters an inconvenient exception remains recognisable.
Four humans, four agents, one difficult job
One of Bagrecha’s thought experiments starts with an ordinary staffing request: a client needs eight Java engineers. Then comes the revision. Four would be human engineers; four would be AI agents. He presented the arrangement as a possible request, an invitation to consider how a software team’s composition might change.
In that picture, agents take on routine coding and debugging. People carry the work of architecture, problem solving and translating a business requirement into a useful design. The example interests him because it changes the manager’s job. A team with agents needs decisions about responsibilities, review and the point at which a person takes over. Giving software a place on a staffing plan does not settle those questions.
There is a revealing tension here. Bagrecha is willing to imagine a different workforce while remaining attached to the craft that makes its output worth having. The human engineer still needs to understand the problem. An impressive quantity of generated code offers rather little comfort when nobody can explain the decision it implements.
The model can stay backstage
By September 2026, Bagrecha was making a related argument to chief executives: begin with the outcome. Time to market, the cost of completing a task and the pace of delivering a product give a business something it can examine. An argument about which model leads a benchmark can easily occupy the meeting while leaving the business question untouched.
He calls the preferred result “invisible AI”. The underlying model can change while the business continues to receive the service it needs. That requires engineering which allows components to be replaced without rebuilding the business logic around them. It also requires a CEO willing to ask for evidence of improvement rather than a recital of fashionable technical nouns.
His distinction between an experiment and a strategic investment is useful here. A project without demonstrated outcomes can remain an experiment, with limits and a test to pass. Calling it strategic does not improve its arithmetic. In Bagrecha’s version of the boardroom conversation, the technology has to account for the work it performs, at the price it costs.
“You don’t need an AI hammer for every nail.”
Dilip Bagrecha, Think AI Podcast
Electricity is useful. Owning a socket is ordinary.
Bagrecha’s writing on competition takes the same line a step further. Access to a foundation model provides a shaky claim to distinction when a competitor can obtain access as well. He compares the models to a utility: a useful underlying resource whose availability shifts attention toward what a company builds around it.
He locates the more durable advantages in proprietary context, integration with real workflows and systems that make the result trustworthy. Those are less photogenic than a model launch. They also demand knowledge of the customer’s actual operations. A product has to fit the way people work, respect the information it touches and offer enough value to become part of the routine.
This is a revealing choice of emphasis for someone selling engineering services. It directs attention toward the patient work of connecting systems and understanding a domain. The attractive promise is a machine doing something clever. Bagrecha keeps returning to the surrounding organisation, with its existing software, obligations and habits. That is where the cleverness has to find employment.
A brake belongs in the machinery
His technical writing becomes quite literal about limits. Autonomous agents can retry failed calls, repeat themselves and consume resources while accomplishing little. In his guidance on circuit breakers, he argues for controls in the surrounding software: time limits, spending limits, capped retries and clear points for human approval.
The distinction matters to his idea of autonomy. A sentence in a prompt asking an agent to be careful cannot carry the same responsibility as an enforced system boundary. Some work can proceed independently. An action involving a payment or a consequential configuration change deserves a defined approval step. Freedom to operate needs a place to stop.
His discussion of token spending is similarly practical. Repeated context, unnecessary retries and expensive models handling simple tasks can inflate a bill. He recommends matching the model to the task and avoiding repeated work. In separate writing on private models, he also weighs the cost of running your own infrastructure against actual usage. A machine kept idle is an expense with excellent availability. His preference is to examine the workload before selecting the arrangement.
The people remain in the photograph
Wishtree’s own current figures describe a business with more than 300 engineers and more than 750 digital solutions delivered. Bagrecha’s work therefore includes the decidedly human business of leading an engineering organisation. His leadership colleagues cover delivery, technology, systems, sales and project management. Even a conversation about autonomous software eventually reaches somebody’s calendar.
His 2026 team offsite offers a less architectural view. The photographs show colleagues together aboard a ship, a substantial gathering temporarily removed from the usual setting of delivery schedules. In his accompanying message, Bagrecha celebrated the laughter and ideas, then announced a return to work with renewed focus. It is a small glimpse of the person behind the deployment vocabulary, pleased to be among the people doing the work.
His public commitment to women’s opportunities adds another personal dimension. Wishtree became a Women’s Empowerment Principles signatory on 8 March 2022. In his statement, Bagrecha identified himself as the father of two daughters and connected that experience to his interest in women’s advancement. He described equal access to opportunities and resources as part of the workplace the company sought to build. The pledge makes a useful counterpart to his engineering arguments: organisational design also determines who gets to act.
A wider market, with the same practical questions
Bagrecha’s LinkedIn profile places him in the San Francisco Bay Area. His professional life crosses markets, while Wishtree lists a presence in the United States, Britain, the United Arab Emirates and India. His public account of entering the US market includes uncertainty about building relationships there, followed by learning through repeated visits and conversations. The geographical ambition came with the ordinary work of getting to know people.
That reach also has an unglamorous application in wholesale distribution. Wishtree’s announced plans for the HARDI Annual Conference in San Diego, scheduled for December 2026, focus on modernising older software, integrating data and improving distribution operations. Bagrecha is listed among the company’s participating leaders. The agenda offers a concrete setting for his ideas: businesses whose systems must support stock, orders and the movement of goods.
For Bagrecha, the interesting future appears to be one in which AI earns a regular place in those operations. He wants systems that can act, with the engineering and accountability to make that action useful. The ambition is substantial, though its daily proof may look rather modest: a process completed, a cost understood, a person able to trust the result. The former payments architect still seems interested in what arrives at the other end.