Modernizing the Power Grid for AI and Rising Demand With SAP

Can electricity grids built for an earlier era support AI data centers, expanding manufacturing, electric vehicles, severe weather, and rising customer expectations at the same time? In this episode of Tech Talks Daily, I speak with Mark Hollis, utility executive advisor at SAP, about the pressures reshaping the utility industry and the practical choices available to leaders today. Mark spent over 15 years at Duke Energy before moving to SAP, where his work gives him visibility into utility organizations across North America. Mark describes a combination of load growth, disruption, long construction timelines, and regulation. Data centers are receiving much of the attention because of the electricity required by AI, but he argues that they are only part of the story. Manufacturing is returning to parts of North America, transport and heating are becoming increasingly electrified, and utilities must prepare for wildfires, hurricanes, winter storms, and other events that affect generation and delivery. The obvious response is to produce additional electricity, but every option comes with physical and commercial limits. Wind and solar contribute to the generation mix, although output depends on conditions. Small modular nuclear reactors could support future demand, but commercial deployment takes time. Batteries can store electricity and release it later, but they do not generate the power they hold. Customer programs can also reduce pressure at busy periods, including arrangements that allow a utility to adjust connected thermostats by a few degrees. This makes modernization a portfolio of decisions rather than a single bet. Utilities must decide how to divide capital among generation, transmission, resilience, customer systems, and new technology. The people who understand existing processes are often the same employees needed to design and implement replacements. At the same time, information technology and operational technology are becoming increasingly connected, forcing companies to reconsider how business functions share information and how technology decisions support outcomes across the enterprise. AI creates another tension because it contributes to electricity demand while also offering utilities new ways to work. Mark says most utilities he meets are cautiously optimistic. Their questions include where to begin, whether the value is proven, how long adoption will take, and whether poor data must be fixed before useful work can start. He warns against choosing the hardest problem first or judging a business process by the forgiving standards people accept from consumer AI tools. His advice begins with the business problem. Automating an inefficient process can make it more expensive and harder to correct. Utilities should define what they need to improve and why, establish connected data with the right business context, set clear quality requirements, and retain human review where errors could affect customers, safety, finance, or regulatory obligations. Mark brings this to life with several utility AI use cases. AI could summarize customer interactions across field service and contact center systems, allowing the next employee to understand what happened previously. It could review billing exceptions during unusually hot or cold periods and support earlier customer communications when consumption is likely to produce a much higher bill. He also discusses using AI to summarize lengthy rate-case rulings before approved changes enter billing systems. During outages, an AI system could help dispatch crews by considering skills, equipment, parts, certifications, location, safety, and customers with medical needs. A human dispatcher could then review and approve the recommendation rather than building the complete schedule manually. The opportunity is real, but so are the limits. Utilities operate regulated infrastructure where reliability, safety, auditability, and public trust cannot be treated as optional features. Where should the industry begin, and which use case offers the right combination of low effort, meaningful impact, and manageable risk? Listen to the conversation and share your thoughts with me.  

What happens when an AI system moves beyond recommending the next sales action and begins running a connected revenue workflow? In this episode of Tech Talks Daily, I speak with Abhijit Mitra, CEO of Outreach, about the operational work required to turn agentic AI into measurable revenue outcomes. Abhijit argues that adding another AI tool can create extra complexity when customer data remains fragmented and applications cannot share context. The starting point is the business process: what problem is being solved, which data supports it, what agents may do, and where human judgment remains necessary. We discuss the difference between a recommendation and an autonomous action. Revenue teams may begin with supervised spot checks while an agent researches accounts, identifies prospects, drafts messages, and runs targeted campaigns. Once the data and results earn confidence, parts of that process can operate continuously. Multi-step work adds another requirement because the output of one agent must become useful input for the next. Research, outreach, coaching, forecasting, and expansion cannot deliver their full value as isolated tasks. Context runs through the entire conversation. Abhijit describes the customer history, product usage, prior interactions, industry signals, buyer priorities, and organizational memory that can turn a generic model response into a commercially useful action. He says access to a frontier model alone does not create a revenue platform because each business still needs its own context layer and controls. We also discuss Outreach's MCP Server and Client, which allow agents to receive information from surrounding systems and return their work to platforms such as Salesforce Agentforce, OpenAI, Anthropic, and Microsoft. That interoperability creates a governance question. Abhijit's advice is to give an agent the same roles, permissions, and data access as the person or team it supports. If the platform cannot control access at that level, he advises companies to wait. The conversation then turns to the changing software model. Abhijit describes a move from assigning SaaS licenses to employees toward deploying agents with particular skills and a defined capacity. That makes workflow design and measurement increasingly important. He recommends establishing a baseline before rollout and tracking revenue against cost through indicators such as win rate, deal size, quota attainment, pipeline movement, forecast accuracy, and seller productivity. Can revenue teams use agents to remove administrative work while protecting customer trust and keeping relationship building human? Listen to the episode and share your thoughts with me.

What would happen if specialty insurance underwriters and risk capital providers could work from the same timely, detailed information? In this episode of Tech Talks Daily, I speak with Jeff Radke, CEO and cofounder of Accelerant, about the infrastructure behind specialty insurance and why his team chose to rebuild it around a data-driven risk exchange. Jeff has spent decades in reinsurance broking, reinsurance underwriting, and specialty insurance across New York, Bermuda, and London. That experience gave him a direct view of a process he describes as expensive, slow, and supported by weak data flows. Jeff explains that Accelerant backs independent underwriting specialists who focus on narrow areas of risk, from pickleball courts to New York brownstones. These teams need the regulatory ability to issue policies and the capital required to support them. Accelerant connects those needs through a shared platform that routes risks to insurance companies and distributes them across a group of capital providers. The economic argument is striking. Jeff says the traditional chain can consume about 40 cents of each premium dollar in expenses and overhead. Accelerant instead seeks portfolio-level solutions across a diverse book of business, reducing repeated negotiations and transfers between intermediaries. He also addresses the tradeoff created by concentrating information in one exchange, including the need to protect data and cash flows when participants depend on a shared platform. Data quality sits at the center of the conversation. Jeff says older policy administration systems often retain only eight to twelve exposure characteristics for each policy, while Accelerant captures over 60 on average. That fuller record gives underwriters and capital providers more information when selecting risk, reviewing performance, or investigating a problem. We also discuss why smaller underwriting organizations may hold an advantage over established insurers. New teams can begin with data at the center of their operating model, while larger companies must change processes built around older systems. Jeff argues that the biggest barrier is often mindset rather than budget. AI has a defined role in that model. Accelerant uses agentic AI to organize varied incoming data, identify products whose performance needs attention, support portfolio construction, and improve internal operations. Jeff draws a firm boundary around responsibility: underwriters remain accountable for underwriting outcomes. His father's advice captures the principle neatly: do not blame the wheelbarrow; responsibility belongs to the person driving it. Could shared data and lower operating expense return more value to policyholders while preserving human judgment? Listen to the conversation and share your thoughts with me.  

Why can an AI pilot produce an impressive result and still fail to create measurable value for the business? In this episode of Tech Talks Daily, I speak with Jitendra "Jit" Putcha, chief operating officer at Tredence, about what the company calls the last mile of AI. This is the gap between generating an insight and making sure it reaches the person, process, and decision where it can produce a useful result. Jit argues that many companies are facing an execution problem rather than a shortage of technology. Models are widely available, and teams can build demonstrations at remarkable speed. The harder task is redesigning a complete workflow so that employees can use AI without leaving one system, checking another, and manually carrying information between the two. Trust, explainability, governance, and continuous evaluation also become harder once a pilot moves from a small group into everyday enterprise operations. We discuss why resistance from employees should not be dismissed as stubbornness. People are trying to understand what AI means for their role, judgment, and future. Jit recommends translating the program into a practical question: how will this make somebody's Monday morning better? He describes human and AI agent teams, along with workshop-based learning that allows employees to solve real problems, test the tools, and understand where human judgment remains necessary. The conversation then turns to measurement. Jit challenges technology teams to move away from vanity measures such as the number of models built or code interactions recorded. Instead, he recommends examining margin improvement, loss reduction, cycle time, conversion, customer satisfaction, and other measures already understood by the business. Jit supports the argument with several customer examples. He says one retail workflow reduced analyst effort by 70 percent, while a manufacturing supply chain platform reportedly produced $10 million in first-year savings. He also describes a supermarket forecasting program that reportedly produced close to $200 million in value and replenishment match rates above 90 percent, along with another modernization program associated with a reported $100 million loss reduction. These are Tredence customer examples shared by Jit during the interview and should be presented as attributed company claims. We also discuss an AI-native operating model built around three layers: foundation, intelligence, and experience. Data infrastructure and governance support the foundation, intelligence turns data into decisions, and the experience layer brings those decisions into human workflows. Jit adds five supporting elements covering human and agent teams, execution rhythm, business measures, the technology ecosystem, and company culture. His final advice is refreshingly practical. Escape the demo trap, prepare the whole organization for deployment and ongoing operation, consider an internal marketplace for reusable agents, and give the supposedly boring work a larger role. Data hygiene, evaluations, governance, change management, and runbooks help AI continue producing value after the launch presentation has ended. Is your company measuring the number of AI projects it has created, or the business outcomes those projects have changed? Listen to the conversation and share your thoughts with me.

What if the vehicles already traveling through our towns and cities could report road damage before a pothole becomes dangerous and expensive? In this episode of Tech Talks Daily, I speak with Jonathan Selbie, CEO of Stockholm-based Univrses, about using computer vision and vehicle sensor data to give road authorities a much clearer picture of the infrastructure they manage. Jonathan's career has taken him from Formula One engineering at Red Bull Racing to unmanned aircraft and autonomous navigation, before bringing those lessons into automotive AI and road monitoring. Univrses can work with cameras installed by vehicle manufacturers or retrofit cameras and processors to vehicles already operating around a city. Waste collection trucks and taxis can continue their normal routes while gathering information about surface damage, obscured traffic signs, roadworks and deteriorating road markings. The video is processed on the vehicle, and authorities receive mapped findings and recommended actions rather than hours of footage. Jonathan explains that some Swedish cities moved from road condition surveys every five years to updates every two weeks. According to the figures discussed in our conversation, one council reduced its pothole count from around 3,000 to 900 in six months. He also says repairing damage at an early stage can cost up to 15 times less than waiting for it to become a major pothole. That changes road maintenance from an expensive reaction into a regular process based on current evidence. We also discuss whether road infrastructure is ready for autonomous vehicles. Waymo uses a broad mix of cameras, radar and lidar alongside detailed maps, while Wayve is pursuing an approach designed to adapt to changing roads without relying on the same level of pre-mapping. Jonathan explains why faded lane markings can reduce the performance of driver-assistance systems, creating a useful feedback loop in which vehicles rely on roads and also provide data to maintain them. The conversation also covers Pirelli's 30 percent investment in Univrses and the combination of connected tire data with forward-facing cameras. A tire can feel the road surface while a camera sees what lies ahead, giving vehicles and road operators different views of the same conditions. Jonathan also addresses privacy, explaining that Univrses detects and blurs faces and license plates before deleting the original imagery. This is a practical example of AI producing value through existing fleets, frequent data and earlier decisions rather than another expensive technology project searching for a problem. Could the cars, taxis and service vehicles already using our roads become part of the infrastructure maintenance system, and would you be comfortable with that if privacy protections were clear? Please share your thoughts.

What happens when a one-hour conversation with a financial advisor creates an entire day of paperwork behind the scenes? In this episode of Tech Talks Daily, I speak with Hardy Michel, Co-Founder of Marloo, about the administrative load limiting how many clients financial advisors can support. Hardy previously helped build retail investing platforms in New Zealand and the UK, where he saw people gain easier access to investments while personal financial advice remained harder to obtain. Before building Marloo, Hardy and his co-founders spent months inside financial advice firms. They interviewed managing directors, compliance leaders, support teams and advisors, then worked beside them as they moved between inboxes, planning tools, client records and compliance systems. This "go slow to go fast" approach helped the team map the complete advice process before deciding where software could remove friction. Hardy says a 60-minute client meeting can produce 10 to 14 hours of follow-up work. An advisor may need to document the discussion, demonstrate why the advice was suitable, complete product research and cash-flow modeling, record fees and disclosures, and prepare a client-facing report that can run to dozens of pages. According to Hardy, the cost and time involved have left some advisors unable to accept new clients for several years. Marloo began as a specialist meeting assistant because note-taking is frequent, painful and driven by regulation. Hardy explains how transcripts created a current source of client context that was often absent from static records. The company then expanded into the work that follows a meeting, including advice documents and presentations, with the longer-term aim of becoming a central working environment for an advice firm. We also discuss the trust required when AI handles personal and financial information. Hardy describes Marloo's zero-data-retention arrangements for certain model APIs and the security information it provides to firms. He argues that specialist systems need to demonstrate how client data is handled and give advisors language they can use to explain recording and transcription to clients. Adoption is another major theme. Hardy recommends a focused two-week trial with three to five likely power users, a defined goal and a clear measure of value. Rather than relying on a successful demonstration, firms should examine whether advisors continue using the product and are prepared to recommend it to colleagues. The strongest business outcome may be what advisors choose to do with the time returned to them. Hardy says some Marloo users have increased client meeting frequency from once or twice a year to five or six times. Should AI in financial advice be measured by the volume of cases completed, the quality of client relationships, or a combination of both? Listen to the episode and share your thoughts with me.

What does it take to move from giving employees AI tools to rebuilding how an organization gets work done? In this episode of Tech Talks Daily, I speak with Oren Levitzky, VP of R&D at Fiverr. Oren has spent ten years at the company, progressing from backend engineer through a series of leadership roles before taking responsibility for Fiverr's AI program. That experience gives him a valuable view of AI adoption from inside a global technology marketplace. He has watched engineering teams move from using ChatGPT as a conversational assistant to GitHub Copilot for code completion, Cursor for context-aware development, and an internal agent ecosystem containing Fiverr's code, data, and organizational knowledge. Oren explains that adding AI to an existing workflow produced useful gains, but it did not completely change how people worked. Becoming AI native required Fiverr to create a dedicated team of engineers, designers, and product managers responsible for building agents around company context and helping employees adopt new working practices. Fiverr reports that this approach has made some development work three to five times faster. Repetitive coding and design tasks can be passed to agents, allowing employees to concentrate on decisions, validation, and accountability. However, Oren is clear that manual code review remains necessary when AI-generated changes could introduce bugs or destructive operations. We also discuss what AI fluency means for hiring. Fiverr has redesigned parts of its engineering recruitment process so candidates can use their preferred AI tools to build an application during the interview. Oren says around 80 percent of the assessment focuses on how candidates work with AI, communicate instructions, make decisions, verify changes, and demonstrate that they understand the resulting code. This creates opportunities for people who can combine technical knowledge with AI fluency, but it also introduces a serious learning problem. Junior engineers may produce work at a speed previously associated with experienced developers without acquiring the knowledge needed to spot errors or question poor recommendations. Oren argues that regular workshops, practical education, self-directed learning, and continued hands-on work are needed to prevent that loss of understanding. His advice applies to leaders too. Remaining close to the work makes it easier to recognize where AI succeeds, where it struggles, and what employees need from management. Beyond Fiverr's internal engineering teams, we consider how AI is affecting the global freelance workforce. Businesses increasingly want people who can take an AI-generated draft and turn it into secure, accountable, production-ready work. Oren points to AI video production as one example where independent creators can produce work that previously required a larger studio, while retaining the judgment and creativity customers value. For leaders hoping to make agentic AI part of daily operations, Oren recommends dedicated resources, structured education, employees who constantly seek better ways to work, and clear measurement. Releasing another tool will achieve little when habits, incentives, and expectations remain unchanged. As employers place greater value on people who can direct, question, and verify AI, how should we prepare today's workforce without weakening the knowledge tomorrow's experts will need? Listen to the episode and share your thoughts with me.

How much control would you hand to an AI agent when the result is a real flight, a real hotel, and a meeting you cannot afford to miss? In this episode of Tech Talks Daily, I speak with Evan Konwiser, Chief Product and Strategy Officer at American Express Global Business Travel, about the role AI can play across search, booking, disruption support, expense management, and the wider managed travel experience. Evan begins with a problem many travelers already recognize. Buying a ticket has become far harder than choosing a departure time and airline. Travelers now face different cabins, fare types, seats, amenities, loyalty benefits, corporate policies, and payment rules. Amex GBT and Ipsos research referenced during the interview also found that four in ten Gen Z business travelers consider arranging work trips too difficult. The challenge for a travel platform is to reduce that complexity while respecting the policies of the employer and the preferences of the person taking the trip. That is where AI becomes promising, but the consequences of failure are unusually tangible. A wrong answer in a chat window is irritating. A travel tool that sends someone to a closed location or recommends a train that does not stop at the required station can damage confidence immediately. Evan describes trust as the deciding factor and argues that business travel may have an advantage over leisure travel because a managed travel provider already knows the traveler's profile, company policy, payment method, and authority to book. We discuss what Evan calls trusted transaction authority. Agentic workflows can help arrange a trip, but most travelers still want to confirm the final booking. Disruption may become one of the first situations in which people accept greater autonomy. If a flight is canceled and time is short, an agent could reserve a suitable alternative, provided the action can be reversed and the traveler can reach a human advisor whenever needed. Evan also describes how AI can identify possible disruption before it happens, prepare alternative routes, and carry the context of a digital conversation to an experienced travel counselor. This matters because automation and human service do not have to operate as separate experiences. Travelers may begin in a self-service channel, move to a person when the situation becomes complicated, and expect the context to follow them. Expense management provides another practical example. Evan believes much of the manual expense report could eventually disappear as trip data, receipts, virtual cards, risk controls, and exception handling work together behind the scenes. He describes guest travelers, contractors, recruits, and event attendees receiving controlled virtual payment cards so ordinary travel spending can be processed automatically while unusual purchases are blocked or reviewed. We also look at bringing travel assistance into tools such as Microsoft Teams. The potential benefit goes beyond convenience. An enterprise assistant may already understand a traveler's calendar and meeting commitments, allowing the booking experience to exclude flights that arrive too late. That context may help employees make better choices while increasing policy compliance, although it also raises questions about data access, responsibility, and how results should be measured. Evan argues that companies should assess AI supported travel at both the program and traveler levels. Time to book and cost matter, but so do satisfaction, policy fit, channel choice, human support, and the quality of the trip itself. He also acknowledges that early agentic chat workflows can take longer than established booking tools, a useful reminder that novelty and improvement are not the same thing. Would you allow an AI agent to rebook a canceled flight automatically if you could reverse its decision, or would you always want to approve the change first? Listen to the episode and share your thoughts with me.

How can data center developers meet soaring demand for AI capacity without locking billions of dollars into buildings that may no longer fit tomorrow's workloads? In this episode of Tech Talks Daily, I speak with Steve Conner, president of EdgeCore Digital Infrastructure, about the decisions sitting beneath the rapid expansion of AI infrastructure. Steve has worked in and around the data center sector since 1998, including the dot-com era and the later growth of cloud computing. That history gives him a measured view of the current rush to build large facilities quickly. Steve argues that AI has intensified what he calls shiny object syndrome. The opportunity is large, but training, inference, and cloud workloads do not all ask the same things of a building. Rack density, floor loading, cooling, electrical design, available space, network distance, and proximity to cloud regions can all affect whether a campus can adapt when customer requirements change. We discuss why EdgeCore has chosen to preserve flexibility in its facilities. A training-focused building might be made smaller because dense racks require less floor space, but future inference workloads may need a wider footprint. EdgeCore therefore accepts additional space in some designs, reinforces floors for heavier equipment, and enables liquid cooling even when a lower-density workload may not need it immediately. Steve presents those decisions as insurance against expensive retrofits or stranded capacity. The conversation also examines EdgeCore's recently secured $1.5 billion in financing. Steve says the covered buildings were fully leased and designed to support mixed cloud and AI workloads. For him, the financing reflects continuing demand both inside established cloud regions and in surrounding markets, while the mixed-use design gives the customer options as requirements develop. These figures and interpretations remain EdgeCore's account of the investment. Site selection is another major part of the equation. Power availability receives much of the attention, but Steve adds network distance, workforce availability, long-term political support, and relationships with utilities and local authorities. He describes looking beyond crowded locations such as Ashburn while remaining close enough to established cloud regions to support different use cases. For me, the most valuable part of the discussion concerns communities. Steve says developers should begin meeting local leaders and understanding local needs before purchasing land. EdgeCore's examples include support for chambers of commerce, first responders, hospitals, fire services, and workforce development. His argument is that a company cannot simply purchase goodwill after construction begins. It has to be present early and demonstrate that the relationship runs both ways. We also address public concerns about water, emissions, energy demand, and jobs. Steve argues that many modern data centers use cooling systems that do not consume water for routine cooling, though his comments apply to the facilities and designs he knows and should not be generalized to every data center. He also notes that AI facilities consume substantial power while arguing that developer-funded transmission upgrades can benefit other users of the grid. The episode closes with a wonderfully plain analogy. Steve describes the data center as the plate rather than the meal. The infrastructure serves whatever workload the customer needs, which is precisely why the plate must be designed for a menu that keeps changing. Are developers doing enough to prepare AI data centers for changing workloads while earning the confidence of the communities around them? Listen to the episode and share your thoughts with me.

What does an AI agent need before it can carry out useful work across the systems that actually run a business? In this episode of Tech Talks Daily, I speak with Daniel Chilcott, Managing Director and co-founder of Flowgear, about the integration infrastructure behind agentic AI, product-led growth, and enterprise automation. Daniel's career began with a ZX Spectrum and a job as the first software developer inside a small business. The company built custom software and a CRM, but customers repeatedly needed that software connected with accounting, ERP, and other operational systems. Building every connection by hand convinced him there had to be a better approach. He created an on-premises integration product in 2007, then co-founded Flowgear in 2010 as a cloud service. The conversation shows how much the market has changed. In Flowgear's early years, Daniel had to explain why integration software belonged in the cloud. Today, roughly half of the company's customers are in the United States, and the larger question is how AI changes the way people build integrations.  Traditional platform vendors often supplied templates or starter packs. Those templates offered a useful starting point, but Daniel says they could create the illusion of a finished solution when every customer still had different processes, rules, and systems. Generative AI offers another route. A user can describe the integration they need, and an agent can create and test the workflow, identify problems, and revise the design. That makes a product-led model more practical because customers can reach a result without first becoming specialists in the platform. Flowgear still supports a visual designer, but Daniel says many customers increasingly build outside the product interface because the integration is part of a wider application or business outcome. This matters because much of the information needed for knowledge work sits behind APIs in ERP, CRM, warehouse management, and other line-of-business software. Reading a document from cloud storage is useful, but an agent becomes far more capable when it can work with operational records and complete an approved action. Flowgear's Builder MCP server is intended to bring that capability into the AI chat or development environment where the user already works. A person can ask for an application, and the agent can create the supporting integration without requiring that person to construct every workflow manually. Daniel is equally clear about the limits. Some business processes contain what he calls irreducible complexity. They carry unusual rules, historic decisions, exceptions, and dependencies that cannot be removed by a cleaner interface or a better model.  Flowgear therefore continues to rely on solution architects who can connect the customer's operational knowledge with the technical workflow. An experienced specialist may identify the question nobody thought to ask because they have seen the failure pattern before. We also discuss the decision to rebuild Flowgear's platform. Daniel estimates that less than five percent of the code from five years ago remains in the current product. The rewrite was difficult, but its timing allowed the company to support generative and agentic AI from the start instead of attaching those capabilities to an older architecture. He describes it as feeling like a startup again, accompanied by the less glamorous work of testing failure modes and making the product dependable. The most human example comes from a customer that used a call center for weekly product reorders. Flowgear helped automate the routine transaction through WhatsApp, allowing the same employees to spend their time on better conversations with customer accounts. It is a useful test for automation: does it merely reduce minutes, or does it create room for more valuable work? Where does your organization need stronger integration before AI agents can become useful across everyday operations? Listen to the episode and share your thoughts with me.