The Work After the Algorithm: Dr. Rajan Gupta on What Makes AI Work in Business

When much of the world was still trying to understand where artificial intelligence might go next, researchers were already working on questions that would later become central to business.

How should machines learn from complex data? How should intelligent systems explain their behaviour? Could information be selectively removed from a trained system? Could machines recognise relationships and structures that conventional approaches struggled to represent?

For Dr. Rajan Gupta, those were not abstract questions. They formed the foundation of a career that began in AI research and gradually moved toward a very different problem: what happens when machine intelligence has to work inside the complexity of a real organisation?

Today, as Director of AI Engineering, Deutsche Telekom Digital Labs, Rajan works across AI engineering, agentic AI, system architecture, production engineering and the evaluation of emerging technologies. His experience spans research, product development, venture-side evaluation and enterprise-scale technology.

Earlier I was shooting for output of a model. Now I am shooting for business outcomes.

A model can perform well technically and still struggle to create value once customers, processes, infrastructure, cost and organisational realities enter the picture. The gap between what an algorithm can do and what an organisation can actually achieve with it is where Rajan sees much of the next phase of AI taking place.

Before AI Became an Operating Problem

Rajan entered AI through a research-first path in the late 2000s, when the nature of digital information was changing rapidly. Images, audio, video, smartphones and digital interactions were producing data at a scale and variety that traditional structured-data approaches were not designed to handle.

His early work included image data and encryption, along with broader questions around information that was increasingly difficult for humans to interpret manually. As the field developed, his research interests moved through areas including machine unlearning, explainability, graph neural networks, deep clustering and generative recommendation systems.

The subjects were technically different, but a common thread ran through them: understanding what makes machine intelligence useful, explainable and controllable.

A model can be studied in isolation. An enterprise system cannot.

Once AI becomes part of a product or workflow, the questions expand. What information does it have access to? What context does it retain? How does it interact with other systems? What happens when something goes wrong? Who is responsible for the result?

At Deutsche Telekom Digital Labs, those questions became part of the production environment. Rajan’s work increasingly moved across agentic AI, architecture, engineering, technology assessment and the translation of business problems into systems that could operate at scale.

The algorithm was no longer the finish line.

The Range Behind the Decision

Rajan’s academic path moved through computer applications, management, business analytics and computer science before doctoral and postdoctoral research. He initially prepared for medicine before moving toward computer science. Later, when commercial work was no longer giving him the technical depth he wanted, he returned more deeply to research.

That combination of technology, analytics and business has remained relevant throughout his career because enterprise AI rarely presents a purely technical decision.

A technical leader may need to understand the model well enough to challenge its limitations, the product well enough to understand whether customers actually use it, the architecture well enough to know whether it can scale, and the business well enough to know whether the resulting system creates value.

As AI moves deeper into the enterprise, the boundaries between technology, analytics and business become less useful. The decision is rarely about one layer alone. It is about whether the layers can work together.

When Accuracy Stopped Being Enough

One experience that changed Rajan’s thinking about product development came while working on an analytics platform designed to make sophisticated data science more accessible to people without specialist technical backgrounds.

The engineering instinct was to keep building. More algorithms meant more capability. More capability appeared to mean a more complete product.

His CEO asked a more basic question: how much of that capability did customers actually need?

If a smaller set of algorithms was sufficient to solve the problems customers cared about, waiting to build a much larger catalogue would delay the opportunity to learn from actual users.

Do they really need those hundred algorithms? Or are they content with twenty of them? If they are content with twenty of them, why are you wasting time building another eighty?

The lesson was not that engineering ambition was wrong. It was that technical completeness and customer value are different measures.

A product team can spend significant time improving a system according to its own definition of completeness while customers are already satisfied with a smaller capability set. The experience shifted Rajan from thinking primarily like a scientist toward thinking more like a product builder.

Generative AI has made that distinction more relevant. Models are improving rapidly. Products evolve while they are being built. The technology available to an engineering team can change before the product itself reaches maturity.

The question is therefore not simply how much the technology can do. It is how much technology the problem actually requires.

Context Is Where AI Becomes Useful

Rajan often describes enterprise context through three dimensions: understanding the domain, understanding the user and retaining relevant history.

Consider a simple customer-service interaction. A customer reports a failed transaction. The system acknowledges the problem and says that it is being handled. The following day, the customer asks for an update. If the system asks the customer to explain the entire problem again, it may know the relevant policy perfectly and still fail the customer.

If I have already given the complaint yesterday, and today again you are asking me the same thing, then it is not intelligent for me.

The issue is not necessarily reasoning capability. It is the absence of continuity.

For an enterprise AI system, context is more than the information retrieved from a knowledge base. It can include the customer’s identity and history, the state of a business process, applicable rules, permissions, previous actions and the domain knowledge required to interpret the request correctly.

That distinction becomes increasingly important as foundation models become more widely available. If many organisations can access comparable model capabilities, the differentiator moves toward what surrounds the model: data, workflows, customer history, business rules and operating constraints.

The model may be broadly available. The context in which it operates is not.

Production AI therefore needs more than a larger prompt. It needs a context architecture that determines what information is relevant, where it comes from, how long it should persist, who can access it and how it affects the decision being made.

The Real Return From Automation

Rajan’s thinking about automation extends beyond the task being automated.

HR provides an obvious example. Employees repeatedly ask about leave, insurance, benefits and company policies even when the information already exists within the organisation. An internal AI system can handle those interactions conversationally and has already processed more than eight million transactions.

The immediate benefit is efficiency. The more important question is what happens to the human capacity that has been released.

If routine questions can be handled by AI, HR can spend more time on culture, collaboration, employee development and problems that require human judgment. Productivity should therefore be viewed less as the elimination of work and more as the reallocation of attention.

Automation becomes strategically valuable when it changes the allocation of human capability, not merely the number of tasks people perform.

When Agents Reach the Edge of the Enterprise

The next step is more consequential because AI is beginning to move from answering questions toward performing actions.

Rajan describes the appeal of an intelligent interface that could allow a person to request an outcome, such as booking a flight, without manually moving between multiple applications. At the interface level, the idea is compelling. The difficulty emerges underneath.

Enterprise applications and backend systems were generally built around conventional software interactions and human users. An AI agent introduces a different execution pattern. It has to understand what action is required, identify the appropriate tool or system, authenticate itself, operate within permissions, invoke the relevant API, handle the response and determine whether the requested outcome was actually completed.

A production agent is not simply:

LLM + prompt + tools.

There is an execution path behind the experience:

intent → reasoning → planning → tool selection → identity and authorisation → API execution → result validation → state update → response

Every step can fail independently. The model can reason correctly but select the wrong tool. The right tool can be selected but the user may not have permission. The API can execute successfully but return incomplete information. The transaction can appear successful while the underlying business state has not changed.

Rajan encountered this directly when implementation exposed the gap between an attractive agent experience and the systems underneath it.

Conceptually it looked fantastic. When we started to implement, we realised that the systems were not ready.

Human employees routinely compensate for these gaps. They know whom to call, which workaround is accepted and which undocumented exception applies. Agents do not automatically possess that institutional knowledge.

Their arrival can expose technical debt that humans have been masking for years: missing APIs, unclear ownership, inconsistent data, weak identity controls and processes that depend on tacit knowledge.

Agentic AI is therefore not only an automation challenge. It is also a test of how machine-operable the enterprise actually is.

From Demonstration to Production

Once AI systems begin making decisions and taking actions, another question becomes unavoidable: how does the organisation know the system is working?

A conventional software test can often determine whether a known input produces an expected output. AI systems are more probabilistic. An agent can produce a plausible answer while using the wrong source. It can select the wrong tool while generating a convincing explanation. It can complete one step correctly and fail later in the workflow.

Evaluating the model alone is insufficient. Production AI needs evaluation across three levels: intent, execution and outcome.

At the intent level, the system has to understand what the user is actually asking and retrieve the relevant context. At the execution level, it has to reason appropriately, select the correct tool, operate within permissions and complete the workflow. At the outcome level, the organisation has to know whether the answer or action was accurate, useful, compliant and tied to the intended business result.

Observability also changes. Latency and errors still matter, but so do model behaviour, retrieval quality, tool calls, agent trajectories, escalation patterns and outcome quality.

Evaluation cannot be a one-time exercise performed before launch. Production AI needs a continuing loop:

observe → evaluate → diagnose → improve → re-evaluate

That loop becomes part of the operating system around AI.

The Economics That Arrive With Scale

Production also changes the economics.

Inference creates recurring costs. Query volumes can grow rapidly. Model providers can change pricing. Architecture influences latency and infrastructure requirements. Retrieval, orchestration, monitoring, security and human intervention add to the operating cost.

A pilot that appears inexpensive at low volume can behave very differently when it becomes a heavily used production service. Economics therefore becomes an engineering concern, not a finance discussion that happens after architecture is complete.

The relevant measure is not simply the cost of an inference call. A better question is: what does it cost to achieve a successful business outcome?

That may include model inference, retrieval, orchestration, tool execution, retries, infrastructure, human escalation and the cost of failures. A system that is technically impressive but too slow, too expensive or too unreliable to complete the intended workflow is not a successful enterprise system.

Rajan’s definition of power is pragmatic. “Powerful is something which gets your work done efficiently.”

The important word is consistency. AI becomes powerful in an enterprise when it can perform useful work reliably over time, not merely demonstrate impressive capability once.

The Discipline of an Investable AI Business

Rajan’s experience with venture evaluation and technical due diligence adds another perspective. Looking at an AI product from an investment standpoint changes the questions.

The first question is not simply whether the technology works. It is whether the problem matters enough for customers to keep paying to solve it.

Then come other questions. Does the product become part of a real workflow? Does repeated usage create a data or knowledge advantage? Can the technology strategy survive changes in the underlying AI platforms? Do the economics remain viable once compute, inference and customer acquisition costs are included?

These questions provide a useful discipline for enterprise AI as well.

A demonstration can prove technical possibility. A durable product has to survive adoption, integration, repeated use, economics and technological change. The venture lens and the enterprise lens therefore converge on the same point: AI has to create value after it leaves the demonstration environment and becomes part of real work.

The Three Layers Enterprises Cannot Outsource

Rajan is not opposed to external technology. If another organisation can provide a capability faster, better or at greater scale, there may be little reason to recreate it internally.

The more strategic question is what the enterprise should continue to understand and control.

Three layers become particularly important: business process intelligence, proprietary data intelligence and integration intelligence.

Business process intelligence is the organisation’s understanding of how work actually gets done, including the exceptions, dependencies, decisions and workarounds that people accumulate through experience. Proprietary data intelligence is the organisation’s ability to interpret its own data in the context of its customers, products and operations. Integration intelligence is the knowledge of how internal systems, workflows and dependencies actually connect.

A model provider can supply the intelligence layer. A systems integrator can accelerate implementation. Neither automatically owns the organisational understanding accumulated over years.

This becomes especially important for mid-market companies, which may have fewer resources to build deep internal capabilities while facing pressure to adopt AI quickly and economically.

The strategic risk is not outsourcing execution. It is outsourcing comprehension.

An organisation needs enough internal capability to evaluate vendors, challenge technical decisions, understand failures and retain long-term operating control.

When Machine Authority Becomes Management Responsibility

As AI systems become capable of acting, governance becomes increasingly concrete.

What information can the system access? What actions can it perform? Which decisions can happen automatically? Where is human approval required? Can the organisation reconstruct what happened? Who can change or stop the system?

These are not simply policy questions. They are architecture questions.

Identity, authentication, authorisation, audit trails, escalation paths, intervention mechanisms and clear ownership become part of the AI system itself.

Rajan’s earlier research interests in explainability, memory and unlearning take on another dimension here. Concepts that begin as technical research questions become connected to privacy, security, regulation and organisational accountability once the system operates in real environments.

The more authority an AI system receives, the more important it becomes to make its boundaries explicit. Governance has to move from policy language into system design.

The Skill Shift Beneath the AI Talent Market

AI is also changing the role of the people who build it.

Earlier data-science teams were often organised around developing, training and tuning models. The centre of gravity is shifting. Frontier model development increasingly requires specialised research, data and compute at a scale that most enterprises do not need to reproduce.

Enterprise value increasingly lies in taking available intelligence and making it work inside products, processes and systems. AI engineers need to understand models, but also orchestration, integration, evaluation, reliability, security, cost and business workflows.

The conventional data scientist is not disappearing. Model development is becoming one capability inside a broader discipline of AI system engineering.

The important shift is from asking:

Can we build the model?

toward:

Can we build, integrate, evaluate, operate and improve the system around it?

That is a different engineering problem.

The Operating Burden of Leadership

The movement from individual technical work into leadership creates another kind of transition.

Earlier roles can provide significant autonomy. Leadership changes the unit of performance. Decisions have to work for teams whose expertise, incentives and constraints may differ.

Rajan describes the priority simply: “Organisation first. Team next. Self last.”

That shift makes communication, patience, conflict management and change management increasingly important alongside technical expertise. It also changes the role of perfectionism.

Technical people naturally want systems and decisions to be completely in order before moving forward. Enterprise environments rarely provide perfect information or unlimited time.

Customers may need a usable solution before every uncertainty has been resolved. Markets may move before the technically ideal answer is available. Teams may need direction before all the information is known.

Leadership therefore involves knowing where precision is essential and where progress is more valuable.

Leadership Lessons From Dr. Rajan Gupta’s Work

• Customer evidence should enter the product early enough to change it. Technical expertise provides direction; real behaviour reveals priorities internal teams often miss.

• Context should be treated as an enterprise capability. Domain knowledge, user history, workflow state and permissions are not supporting details; they shape whether AI becomes relevant.

• Automation should be judged by redeployment, not only reduction. Efficiency has limited value when the released human capacity has no better destination.

• Agents require machine-operable enterprises. The systems around them need clear interfaces, permissions, ownership and validation paths before autonomy can scale.

• AI economics should enter architecture early. Technical ambition has to survive inference costs, infrastructure costs, vendor dependency and production usage.

• Enterprises can outsource technology without outsourcing comprehension. Leaders still need enough internal understanding to challenge vendors, interpret failures and protect operating control.

• Machine authority should expand only with explicit responsibility. Governance is strongest when boundaries, approvals, audit trails and intervention rights are designed before failure.

• AI talent is moving toward system judgment. The scarce skill is connecting model capability with workflows, reliability, economics and business outcomes.

• Restraint is a technical strength. The best decision is often not the most advanced system, but the one the problem can justify and the organisation can operate.

The Work After the Algorithm

Artificial intelligence has moved rapidly from research environments into the operating core of organisations. Questions that once belonged primarily to computer science now sit inside customer experience, product development, workforce design, infrastructure, economics and governance.

That changes what enterprise AI competence means.

Model capability still matters, but it is only one layer. Around it sit context, reasoning, action, integration, evaluation, observability, economics and governance. Around those technical layers sits the organisation itself: its processes, data, people, incentives and decisions.

Rajan’s career spans both sides of that transition. His early work focused on questions beneath machine intelligence. His current work increasingly concerns what happens when AI encounters real customers, real workflows, real infrastructure and real business expectations.

The real test of enterprise AI will be less about demonstrating what a model can do and more about building the environment in which it can work reliably. A strong model inside a weak operating environment can still produce weak outcomes. A capable agent inside an unclear workflow can expose problems rather than solve them. An automation programme without a plan for the human capacity it releases can leave much of its potential unrealised.

The model is increasingly becoming a component. The competitive advantage lies in the system around it: the context that informs it, the workflows it can enter, the controls that constrain it, the evaluation that measures it and the economics that allow it to operate at scale.

That is the work after the algorithm.