Tech Talks Daily

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.

Would employees use AI differently if a practical project could earn them a 2 to 4 percent salary increase?
In this episode of Tech Talks Daily, I welcome back Rytis Lauris, CEO and co-founder of Omnisend. We last spoke in December 2022, before generative AI became part of almost every technology and workplace conversation. This time, we examine why so many company AI projects attract attention during a demonstration but never become part of the work people do each day.
Rytis calls this the "beautiful junk" trap. A prototype can look impressive, yet employees return to the old process when the agent makes mistakes, lacks context, or requires extra effort. He believes prompting is partly a delegation skill. People must define the result they want, supply enough context, and review the output. Managers face an unusual tension because employees often perform best with room to use their judgment, while AI agents require much tighter instructions.
Another problem is the way organizations treat implementation. A traditional CRM project begins with mature software, installation, training, and a defined handover. An AI agent may begin with inconsistent results and improve only through continued use, evaluation, and correction. Rytis argues that businesses must treat agents as products that require ongoing ownership rather than projects that end after launch.
Omnisend's response began with broad access to AI tools. The company then created recurring AI days when most employees canceled meetings and spent time experimenting. Accountants, lawyers, and other teams began building their own tools rather than waiting for developers.
Rytis shares an accounting agent that checks whether employees have supplied reimbursement documents, sends reminders, and asks a person to intervene when repeated requests fail. He also describes a legal-review agent that examines new AI tools and assigns a green, yellow, or red status. Green tools can be used without further review, yellow decisions go to legal counsel, and red tools are rejected.
Omnisend is now formalizing this approach by offering salary increases of between 2 and 4 percent. Rytis says individual contributors must demonstrate that AI is saving time on repetitive, low-value work. Employees can qualify by building a useful tool, helping colleagues create one, or becoming an effective adopter. Managers are also assessed on whether their teams are using AI to reduce time spent on routine tasks.
The policy creates a genuine debate. Financial rewards can give employees permission and motivation to change established habits, but they could also encourage people to automate work simply because a reward is available. Rytis says Omnisend has not identified cheating or harmful behavior so far. Decisions are decentralized to managers, which gives teams flexibility but also places considerable responsibility on management judgment. He notes that Omnisend has approximately 260 employees, a scale that may make this approach easier to oversee than it would be inside a much larger enterprise.
The conversation includes an example of a recurring agent designed to identify and recover failed customer payments. It assesses risk signals, detects failures, contacts customers through several channels, brings account managers into the process when needed, and reports results through a dashboard. The goal is to remove friction for Omnisend and customers rather than adding an AI layer with no clear result.
Rytis also offers a candid account of customer-support automation. He says AI now handles around 40 percent of Omnisend's support tickets. When the system launched two years earlier, customer satisfaction was almost three times lower than the human team's result. Two employees worked continuously on training the agent, and Rytis says human and AI customer-satisfaction levels are now comparable. The figures are Omnisend results shared by Rytis during the interview and should remain attributed to him.
A separately recorded section also covers AI inside the Omnisend product. Rytis describes recommendations that identify possible improvements in marketing automations, natural-language segment creation, and MCP connections that let customers work through ChatGPT or Claude before sending campaigns through Omnisend. He says these capabilities have received the strongest customer usage among the company's AI work.
This is an honest discussion about incentives, experimentation, uncomfortable tradeoffs, and the patience required to turn an unreliable agent into a dependable colleague. Would a salary increase encourage meaningful AI adoption inside your organization, and who should decide whether the result deserves the reward? Listen to the conversation and share your thoughts with me.

How do you give sports fans deeper insight into a live match without covering the action with statistics they never asked for?
Two years ago, I spoke with Patrick Mostboeck in episode 2788, How Sportradar Are Revolutionizing Sports with AI. Patrick returns to Tech Talks Daily as Senior Vice President of Fan Engagement at Sportradar for a timely conversation during the U.S. Open about how AI and real-time sports data are changing the way fans follow a match.
We begin with the move from scores, schedules, and basic statistics to thousands of data points that can describe what is happening on the court or field. Patrick explains that the value comes from context. In tennis, ball position, shot type and player movement can reveal patterns around fatigue, court positioning and momentum that may be difficult to see from the television picture alone. AI can process those signals quickly enough to help broadcasters and digital services explain why a match may be changing.
That creates an obvious temptation to show everything. Patrick is candid about the lesson Sportradar has learned from putting products in front of users: less is often more. A product team may want to display every feature it has built, while the fan simply wants to understand the action. The technology works best when the improvement feels natural and the viewer does not have to fight through a stream of graphics.
We also consider the second screen. Many of us now watch sport with a phone or tablet nearby, checking other scores, following another match or looking for an explanation of a moment we have just seen. Patrick argues that media companies and rights holders can support those habits by offering different routes into the same event. A first time tennis viewer may need immediate context, while a fan who has watched the sport for 25 years may want deeper performance data. Personalization can serve both groups without taking away the shared experience of live sport.
Patrick explains how Sportradar's 4Sight combines 3D data visualization, contextual data, and real-time insight inside live streams. The aim is to identify relevant moments and provide a clear narrative rather than add graphics for their own sake. He also describes official sports data as infrastructure that rights holders can actively develop and commercialize across media, advertising, coaching analytics and other services.
For organizations wondering where to begin, Patrick offers a practical sequence. Start with the fans and identify the information they value before and during an event. Assess the quality and history of the data already available. Then speak with partners who understand how that information can support useful products and sustainable commercial models.
We close by discussing prediction. Better data can help systems model possible outcomes for fans, media teams and coaches, but sport still retains the uncertainty that makes it worth watching. Will predictive insight deepen our appreciation of the action, or could too much information remove some of its magic? Listen to the conversation and share your thoughts with me.

What if your website already supports post-quantum cryptography, but nobody inside your organization knows how, why, or which provider controls it?
I speak with David Warburton, Director of F5 Labs Threat Research, about new F5 research examining post-quantum cryptography across the world's top one million websites. According to the research discussed in our conversation, 54% now support PQC. It is an encouraging sign that preparations for future quantum threats are entering mainstream infrastructure.
That figure is also easy to misread. David explains that much of the adoption comes from cloud and CDN providers enabling hybrid post-quantum protection for their customers. A smaller business could therefore appear better prepared than a large enterprise simply because its provider activated the technology automatically. However, that customer may have little understanding of the chosen cipher, the protection applied elsewhere, or the dependencies created around a small number of technology companies.
David says the adoption rate looks very different when major CDN providers are removed from the data. This raises an important question about whether businesses are developing their own post-quantum security capabilities or temporarily benefiting from decisions made on their behalf.
We discuss why current deployments combine established cryptography with newer post-quantum algorithms. This hybrid approach protects compatibility while browsers, APIs, operational technology, IoT devices, and older enterprise systems catch up. It also carries performance costs through larger cryptographic material and increased network traffic. David argues that crypto agility matters because organizations need the ability to change algorithms, certificates, and encryption methods as threats develop.
The conversation also moves beyond encrypted traffic. Harvest now, decrypt later attacks involve collecting sensitive information today so it can potentially be decrypted when capable quantum computers arrive. David believes authentication and digital identity could create an even greater concern. A quantum computer able to produce valid certificates could potentially impersonate trusted websites, signed software, devices, or firmware.
Legacy infrastructure remains one of the largest barriers. F5 Labs found that roughly one in ten leading websites lacked TLS 1.3 support, preventing them from supporting current hybrid PQC connections. David also explains why Germany and France may trail countries including the US, UK, Australia, Ukraine, and Singapore, despite strong national policies. Factors include digital sovereignty concerns and the concentration of older manufacturing and operational systems.
For leaders beginning this work, David recommends speaking with suppliers, establishing internal ownership, reviewing business continuity plans, and creating a cryptographic bill of materials covering certificates, algorithms, libraries, applications, and devices.
I'd love to hear your thoughts, so does your organization know where its cryptography lives and who controls its post-quantum readiness?