The Chief AI Officer: Scientist, Architect, Coach — Rania Khalaf, WSO2

Hiring a Chief AI Officer creates an immediate scope problem: AI can touch products, operations, revenue, employee skills and customer relationships. Assigning all of that to one person can produce an overwhelming job before it produces a coherent strategy. Rania Khalaf, Chief AI Officer at WSO2, draws on nearly two years in the role and about five years in related roles to explain how to give it a workable shape.

The opening audience questions establish two useful distinctions: does the company build and sell software, and does someone other than the CEO or CTO lead AI? The same title can describe very different responsibilities depending on company type and AI maturity. The person’s background adds another dimension. Some companies create the role around a particular individual; others recruit for a specific need, then adjust the scope to the person they find. Sometimes the responsibilities split into two jobs.

Khalaf’s response to that ambiguity is to divide the work into three focus areas: scientist, architect and coach. The division makes it possible to discuss what the company needs, what the leader should spend time doing, and which responsibilities need complementary people.

The three focus areas describe different kinds of work, even though all can involve building:

• Scientist: Explore, experiment and build to understand what the technology can do.
• Architect: Connect that capability to company strategy. For a software company, this includes new products and changes to existing products. Elsewhere, it can include productivity, cost reduction, new revenue streams or access to new markets. Board-facing responsibility also means explaining how the AI work helps the company and its customers.
• Coach: Help employees and customers understand, adopt and use AI. Education, repeated communication and advice are substantial parts of the job.

Coaching was the surprise after twenty years at IBM Research, where Khalaf had run about a third of the global AI research organization. Research leadership had not prepared her for how much time adoption requires. Customer conversations begin with the customer’s problem and an explanation of how to approach it. If WSO2’s technology does not fit, the advice can point elsewhere. Customers who use none of its AI capabilities may still need help thinking through future possibilities.

Each hat also has a slider. The scientist ranges from exploring existing technology to inventing new technology; a PhD is not required at the exploratory end. Khalaf nevertheless recommends keeping some people experimenting, because a fast-changing field requires direct experience with new capabilities. The architect ranges from business stewardship to reshaping company strategy. A steward evaluates proposed projects, prioritizes them, allocates a budget, manages delivery and reports results. That position can demand more business knowledge and operating skill than deep AI expertise.

The coach’s slider runs from inward to outward. A company still learning to use AI needs employee education and opportunities to experience limitations such as hallucination firsthand. A more mature company may spend more time helping customers and the community. These are settings to choose for the organization, rather than stages every leader must pass through in the same way.

Khalaf used Claude and Gemini to map résumés and job postings onto these sliders. That exercise supplied another way to examine how a person’s skills influence the role; it is an exploratory comparison, rather than an established hiring test. Her own career provides the more concrete examples.

After IBM Research, Khalaf joined an agricultural biotech unicorn in the Cambridge area. It used CRISPR on corn, soy and wheat to produce plants that made more food and used less water. Validating a gene edit could take ten years and substantial land. The opening for AI and data work was therefore upstream: help scientists form better hypotheses about which edits to attempt before committing to those expensive experiments.

The mandate soon expanded. The company had strong geneticists and agricultural specialists, but fewer engineering specialists and no data engineers. Being the “computer person” brought responsibility for IT and hiring a CISO as well as AI. Because the business sold bags of seeds, it could buy infrastructure rather than build a platform to sell: it became an AWS shop and purchased Databricks. Engineering time covered both gene-discovery algorithms and ordinary IT changes, including a move from Box to Microsoft. The latter work was useful, but it was not where Khalaf found her joy.

At WSO2, the balance is approximately 20% scientist, 60% architect and 20% coach. A small research team supports the scientist work, while company strategy centers on the agentic enterprise fabric. About 75% of employees are technical, and the workforce is curious enough that much of the coaching points outward to customers. The allocation of time across hats and the position of each slider are separate choices: spending 20% of the job coaching does not say whether that coaching serves employees or customers.

The biotech work often needed established techniques, clean and integrated data, and changes to existing processes. Consider the corn embryo example. Scientists hypothesized that embryo size indicated how likely the next gene-editing step was to succeed. Human measurement was too costly, so they asked whether AI could perform it. Khalaf’s computer-vision background led to a simpler choice: blob detection, using basic computer vision without machine learning.

The change was from an expensive manual measurement to a simple algorithm that Khalaf reports worked well. The useful capability was measuring the embryo; that measurement could then serve the scientists’ hypothesis about success in the next step. The account does not quantify measurement accuracy or establish the hypothesis’s predictive strength, so the result supports the choice of a simpler measurement method rather than a claim that it improved gene-editing success. The example makes the architect’s decision concrete: identify the operation that needs help, then choose the technique that supplies it.

Across these settings, three questions help shape the role: does the company sell software, is its workforce mainly technical, and where is it in its AI journey? They explain why one organization needs infrastructure and inward education while another needs product strategy and outward advice.

A request to measure tokens as a way to show how much AI the company used received a firm no. Token consumption is easy to count and easy to game. If the target rewards consumption, people can increase consumption without improving their work. Khalaf instead looks at whether AI capability has spread through the organization and how deeply it changes what teams do.

The organizational measures answer different questions:

• Workforce fluency: Can people in marketing and engineering do enough with AI to improve their own work, or does every request depend on a few specialists in a center of excellence? WSO2 has a small central AI team, an AI lead in every product, and people developing AI capabilities within each product team. In AI-first products, everybody works on AI.
• Depth of adoption: Is a team polishing emails or using code completion, changing an entire workflow for a better outcome, or working alongside agents it can instantiate? Different teams occupy different points on that spectrum.
• Tool availability: Does the company actually provide access through subscriptions, reimbursement, team accounts or enterprise accounts?

GEO—generative engine optimization—adds a discoverability question: can LLMs find the company and understand what it does when someone searches? Khalaf describes this as ongoing work whose methods are still difficult to pin down. The accompanying anecdote captures the tension: someone frustrated by a web written for agents had decided to let LLMs read and summarize it, reserving conversation for humans. Making information accessible to models can create pressure on its usefulness to human readers.

Product strategy initially asked what WSO2 should build, what it should extend and where it should partner. It then moved toward making every product consumable by agents and LLMs. Supporting an agent inside a product and allowing an agent to use that product are different requirements. In the previous year, WSO2 added first-class support for agents, LLMs and tools across its products. In the year of the talk, the goal was to provide the documentation and interfaces agents need to use them, including MCP servers, skills and CLIs.

Two adjacent decisions matter as usage changes:

• Agent-proof pricing: Per-seat pricing raises questions when agents generate consumption without corresponding human seats. Khalaf reports that WSO2’s pricing is consumption-based, tying the model to usage.
• Dogfooding with feedback: Internal use can expose product problems, but mandatory use alone does not improve the product. An anecdote about employees whose feedback went nowhere motivates the requirement to close the loop: teams should use the stack because it helps them, and their experience should influence improvements.

Market and ecosystem measures look beyond internal activity. Earned thought leadership includes invitations to speak, publications and press attention generated by interesting work. Analyst recognition, customer adoption and concrete customer use cases offer other signals. For a company Khalaf describes as 100% open source, community participation, adoption, stars and forks also matter.

Annual recurring revenue from AI products remains part of the picture. Some products are too new to generate much ARR, so adoption and ecosystem signals help assess progress while they get established. The measurement set should change as the products and company mature. That follows directly from the incentive problem behind the token refusal: people optimize what gets measured, so the measures need to reward the next useful change.

WSO2 provides the product example behind the architect role. At the time of the talk, Khalaf describes a roughly twenty-year-old company with about 150 million in ARR and software used in over 90 countries across six continents. Its established portfolio spans API platforms, integration platforms, identity and access management, and an internal developer platform. The AI strategy builds on those existing responsibilities.

The extensions follow the jobs those platforms already perform:

• API management → AI gateway: AI APIs are still APIs, but their interactions need different management. The API platform gains an AI gateway to govern those interactions.
• Human identity → agent identity: Experience managing identities and access for humans becomes the basis for managing agent identity.
• Integration → agent building: The integration platform gains an agent builder.
• Individual capabilities → lifecycle management: An agent platform brings these capabilities together to manage the whole agent lifecycle. Agent Manager is the newest release named in the talk.

How do the existing platforms contribute to the new agent platform? The diagram shows the stated product relationships. API governance, identity and integration provide different capabilities that the agent platform brings together. This is the architectural direction described in the talk; it does not specify runtime call order or deployment topology.

The scientist work continues alongside that strategy. The small research group produced three publications that year; two involved undergraduates in Sri Lanka publishing for the first time, and one won a Best Paper Award. The two hats therefore coexist: research produces new work while architecture incorporates AI capabilities throughout the company’s digital fabric.

The ending returns to organizational design. A Chief AI Officer must work closely with many other parts of the company, so Khalaf recommends strong CEO backing and a strong relationship with the CEO. The role’s cross-company scope makes that support consequential: product strategy, employee adoption and customer work all depend on cooperation beyond the AI team.

Ownership can take unexpected forms. In some AI-forward companies, the Chief Product Officer and Chief AI Officer are one person. In some non-software companies, the head of HR has become the head of AI, on the reasoning that agents are part of the workforce and HR manages the workforce. Khalaf is openly unsure about that arrangement. These examples show companies still deciding which existing responsibilities should absorb AI leadership; they are not recommendations for a universal reporting structure.

For someone considering the role, its fluidity also creates room to choose. Khalaf closes with advice to seek the intersection of what you are good at, what you love, what the world needs and what you can be paid for. Her biotech experience gives that advice a practical edge: a valuable mandate can still grow into work that does not suit you. Shape the role around a good match, arrange for others to handle responsibilities that fit them better, or find a company whose needs align more closely with your strengths and interests.