Tech Talks Daily

Neil C. Hughes

If every company is now a tech company and digital transformation is a journey rather than a destination, how do you keep up with the relentless pace of technological change?

Every day, Tech Talks Daily brings you insights from the brightest minds in tech, business, and innovation, breaking down complex ideas into clear, actionable takeaways.

Hosted by Neil C. Hughes, Tech Talks Daily explores how emerging technologies such as AI, cybersecurity, cloud computing, fintech, quantum computing, Web3, and more are shaping industries and solving real-world challenges in modern businesses.

Through candid conversations with industry leaders, CEOs, Fortune 500 executives, startup founders, and even the occasional celebrity, Tech Talks Daily uncovers the trends driving digital transformation and the strategies behind successful tech adoption. But this isn't just about buzzwords.

We go beyond the hype to demystify the biggest tech trends and determine their real-world impact. From cybersecurity and blockchain to AI sovereignty, robotics, and post-quantum cryptography, we explore the measurable difference these innovations can make.

Whether improving security, enhancing customer experiences, or driving business growth, we also investigate the ROI of cutting-edge tech projects, asking the tough questions about what works, what doesn't, and how businesses can maximize their investments.

Whether you're a business leader, IT professional, or simply curious about technology's role in our lives, you'll find engaging discussions that challenge perspectives, share diverse viewpoints, and spark new ideas.

New episodes are released daily, 365 days a year, breaking down complex ideas into clear, actionable takeaways around technology and the future of business.

Play

Open in

94 episodes
daily
Avg 26 min
English

Episodes 94

Newest Oldest Longest

All20 Unplayed20 In progress0 Played0

Counted on this page — what you have heard stays on this device, so it is not something the list can be paged by.

#3786
Yesterday · 23 min
Using AI to Support Human Skills With Taskrabbit
What does useful AI look like when the work still needs someone to arrive at your home with the right skills and tools? In this episode of Tech Talks Daily, I speak with Ania Smith, CEO of Taskrabbit, about the relationship between digital technology and practical work. We discuss furniture assembly, TV mounting, and the decisions involved in connecting a customer with someone who can complete the job. For Ania, the opportunity is to make that connection easier while keeping the people doing the work central to the experience. A TV mounting request sounds straightforward until you consider the details. The person arriving may need experience drilling into a brick wall, the appropriate tools, availability at the right time, and a price that works for the customer. Ania describes how Taskrabbit uses data and AI to improve matching across those factors. She also discusses tests designed to ask customers better questions about what they need before recommending a tasker. Trust runs through the conversation. Inviting someone into your home involves a different decision from clicking on a product listing. Ania explains how the platform learns from taskers' experience, the jobs they complete, and the work they do well. The aim she describes is a useful match and a completed job that gives the customer confidence to return. We also hear what she says taskers want from technology, including flexibility, transparency, and a clearer understanding of how to find work and price their time. I ask how the team decides whether an AI feature is making a difference. Ania describes testing new features with control and treatment groups, then examining whether they make matching easier and whether the job actually takes place. She acknowledges that introducing AI can sometimes add friction. I found that a useful management lesson because it ties investment to the experience of the people using the service, rather than assuming that another AI feature must represent progress. One of the most revealing moments comes from a conversation Ania had with a customer in Brooklyn. Asked about an AI-related booking idea, the customer expressed strong opposition to AI. Ania uses the story to reflect on the assumptions people can make inside San Francisco's technology industry. It is one person's view, rather than a survey of customer attitudes, but it makes the case for continuing to ask questions when a product team thinks it already knows the answer. We also discuss practical skills, careers, and the value of judgement, empathy, and relationships. Ania believes the unpredictable work involved in home services remains difficult to automate. Her comments are a perspective on the work Taskrabbit sees, rather than a guarantee about the future of robotics or employment. The useful question for leaders is how technology can help people bring those skills to the work customers need done. For me, the conversation returns to a familiar principle: technology earns its place when it helps people. In a marketplace, that requires listening to both the customer booking a task and the person accepting it, then testing what changes for each of them. I would love to hear your experiences, so please share your thoughts. Where has AI made a service easier to use, and where would you prefer a company to focus on the human relationship?
#3785
Thursday · 29 min
How Deloitte Measures the Cost of Enterprise AI
Could you explain why your AI bill rose and what the business got in return? I asked Jim Rowan, US Head of AI at Deloitte, because a total spend figure tells a finance team how much it paid, but gives it little help deciding which work to expand. In Deloitte's State of AI in the Enterprise survey, 71 percent tracked total AI interface and API spend, 51 percent tracked token volume, and 44 percent tracked the cost per unit. Jim suggests looking at what it costs to finish a task to an acceptable standard. We talk about what surrounds the model: the tools it can call, the information it can retain, and the permissions it needs to work with company systems. Jim gives a simple example. An email connection can let an agent read messages, draft a reply or send on someone's behalf. Each step carries different consequences. Getting that decision right can take longer than choosing the model, especially when an agent needs access to a system the company has relied on for decades. Jim also explains why he'd start with a company's existing approval limits before giving an agent authority to act. The same payment might require review at a small company and fall within routine approval limits at a larger one. Deloitte's survey puts that discussion in context: 40 percent reported allowing AI to execute decisions or actions without human approval to at least a moderate degree, while 23 percent reported unclear accountability for negative outcomes. Those are separate findings and tell us nothing about how much the groups overlap. We finish with a question for anyone tempted to swap models after the next release. Does it do your work better, and is the improvement worth the cost of testing and switching? Deloitte's survey also found that 28 percent reported revenue gains from AI, up from 20 percent in the previous edition. That's encouraging, although reported revenue gains do not establish that a project paid for itself. I'd love to hear your experience. What do you measure to decide whether an AI workflow deserves a bigger budget?
#3784
Wednesday · 23 min
Recovering what matters first with Fusion Risk Management
If your business lost several systems at once, would the recovery order reflect what your customers need most? In this episode of Tech Talks Daily, I speak with Mike Campbell, CEO of Fusion Risk Management, about operational resilience and the connections that can turn one disruption into a wider business problem. We discuss why application recovery, supplier continuity, employee knowledge and customer service need to be understood together when leaders decide what to restore first. Mike shares an example involving an unnamed retailer whose existing IT recovery plans followed a logical technical sequence. During a demonstration using those plans, he says the business identified a different priority: restoring its online presence before concentrating resources on stores that had some manual alternatives. The lesson is about the assumptions inside the plan. This was a planning example, rather than evidence of a measured recovery during an actual outage. What interested me was the distance between knowing which applications sit on a server and knowing which business activities depend on them. That connection affects how teams judge financial impact, customer consequences and the order in which work should happen. It also explains why operational resilience is a boardroom discussion, with choices about suppliers, investment and acceptable disruption sitting alongside technical decisions. We consider the role of simulation and testing across different scenarios. Mike describes how Fusion's platform can help teams compare variations and identify recurring weaknesses. Those findings depend on the information and assumptions behind the model, and the conversation doesn't establish that a simulation can guarantee what will happen in a real incident. It does offer a useful way to question whether a single rehearsal has covered enough possibilities. There is also a very practical communications example. If the usual email service becomes unavailable, teams need a way to coordinate that doesn't depend on the same failed services. Mike argues that deciding this while normal communications still work is much easier than trying to assemble an alternative during disruption. Finally, we discuss people as potential single points of failure and the decisions involved in relying on one supplier. Resilience becomes something leaders consider when designing the business, supported by testing and an understanding of the consequences of different choices. Please share your thoughts with me. Which dependency would you examine first to find out whether your recovery plan matches the business your customers rely on?
#3783
Tuesday · 23 min
Understanding the Data Costs Behind Enterprise AI With Acceldata
What happens to your AI budget when one business question becomes a series of data queries across several systems? In this episode of Tech Talks Daily, I speak with Rohit Choudhary, founder and CEO of Acceldata, about the work taking place behind an AI response. An agent may need to find information, call several tools, and repeat parts of that process before it can return an answer. Each step can consume resources, and the person asking the question may have little visibility into the infrastructure activity it creates. Rohit uses the example of looking for jewelry without knowing which vault contains it. The analogy helps explain why an AI system can spend time and compute finding the right source before it does anything useful with the information. We discuss his view that repeated queries and tool calls are putting pressure on enterprise infrastructure budgets, particularly where data is spread across older systems and cloud platforms. His banking example brings the problem into focus. Information can pass from mainframes through multiple processing stages before reaching the applications people use. Copies may represent different stages of transformation, and the data that is suitable for one business purpose may be unsuitable for another. An agent needs to use the appropriate source, while the organization needs to understand the reliability and cost of that decision. The banks are not named, and the example should be understood as Rohit's account of the patterns he sees. We also discuss why data quality cannot be separated from governance. Different business teams have different requirements, but AI services can draw on information that crosses those boundaries. Rohit argues for controls that operate throughout the data pipeline, including access restrictions, quality checks, and reconciliation. The business question is whether a policy actually changes what a running system can do. One of his clearest principles is that an agent acting for a person should follow that person's permissions when working with enterprise data. We talk about how common standards can coexist with decisions made by individual teams about where data should live and which infrastructure best serves a particular use case. The conversation does not offer a universal answer about who should own every cost, but it does make the case for consistent controls across separate budgets and responsibilities. Rohit also describes Acceldata's X-Lake platform and its approach to bringing intelligence to distributed data. Alongside the architecture discussion, I ask how leaders can distinguish productive AI activity from repeated processing and experiments that never become useful services. He expects a period of experimentation followed by a closer assessment of which applications provide lasting value. Faster application development can widen access to information, but it also makes it easier to build something whose ongoing cost has not been fully considered. Finally, we consider the consequences of using unreliable data. Rohit's credit and drug-trial examples are hypothetical illustrations of how errors can influence decisions. They reinforce a practical question for anyone expanding an AI service. Can you explain the information it used, the permissions it followed, and the resources it consumed? I would love to hear how your organization is approaching this, so please share your thoughts. Are you measuring the full data and infrastructure cost of an AI answer, or mainly the model bill?
#3782
Monday · 24 min
Securing AI Generated Code Without Losing Speed With Checkmarx
If AI can help anyone create an application, who checks whether the result is secure enough to put into production? In this episode of Tech Talks Daily, I speak with Frank Emery, VP of Product Management at Checkmarx, about the skills and security practices needed as AI becomes part of software development. We begin with developers entering the workforce alongside coding assistants and the experience they still need to build. Frank argues that architecture, review and an understanding of what code actually does become increasingly valuable when generating that code takes less time. We discuss what happens when output grows faster than teams can review it and vulnerabilities accumulate across repeated changes. I ask who should own the risk when AI-generated code passes through several tools and teams. Frank places responsibility with the organization releasing the product, supported by developers who validate their work, team leaders who maintain that discipline and application security teams that establish standards. He also explains why a feature behaving as expected does not establish that it is secure. The conversation considers how much independence coding agents should have. Frank describes the importance of existing controls, the difference between routine changes and architectural decisions, and the need to separate code generation from security testing. We then discuss layered checks across the development process, with quick feedback during generation, further checks around pull requests and deeper testing as an application develops. The aim is to make each check appropriate to the stage rather than applying every test at the earliest possible moment. We close by considering continuous validation and the measures that can show whether a team is reducing risk. Discovery time, detection quality, remediation time and exposure all offer a more useful perspective than counting how much code has been produced. For leaders adopting AI development tools, the conversation raises practical questions about speed, responsibility and the judgment needed to release dependable software. How is your organization reviewing AI-generated code, and what would help your teams build with greater confidence? Please share your thoughts with me.
#3781
Sunday · 28 min
Controlling AI Agent Access and Accountability With Ekco
What happens when an AI agent pursues an approved task in a way nobody expected, using access that reaches further than it needs? On Tech Talks Daily, I'm joined by Jonathan Trayers, a director at Ekco, to discuss the security decisions behind agentic AI. The conversation focuses on what changes when a system can act with credentials, connect to business applications, and trigger workflows. A useful answer in a chat window and an automated action inside a company create different responsibilities. Jonathan describes working with both deterministic workflows, where rules specify what should happen, and agentic steps, where AI interprets a situation before deciding what to do. Bringing those approaches together raises practical questions about boundaries. Which actions can the system take, what information can it access, and where should a person remain involved? What interested me was his emphasis on limiting the impact of unexpected behavior. Predicting every failure is unrealistic, so he argues for reducing the area an agent can affect. The permissions attached to its identity help determine that boundary. An agent given broad access may be able to create problems across several systems, even when its original assignment sounds narrow and reasonable. We discuss separate identities for agents and their connections, restricted permissions, continuing monitoring, and the ability to revoke access. Jonathan also describes governance as a series of practical decisions about the use case, the risks the business accepts, and the people responsible for approving the deployment. Prompts can express instructions, while controls around the systems an agent reaches need their own attention. Testing is another part of that process. Jonathan recommends beginning in a controlled environment, observing the outcome, and then using supervised operation before handing over greater responsibility. His invoice example makes the point understandable. Processing an invoice and authorizing its payment involve different consequences, so the workflow should reflect that difference rather than giving one automated process every permission at once. We also consider what this means for smaller businesses. Jonathan's concern is that companies with limited security resources may already have broad access arrangements, which can be carried into AI deployments. Company size alone does not determine exposure, but understanding accounts, permissions, software, and patching remains part of managing it. His argument is to apply those disciplines as AI adoption develops, rather than waiting for a new platform to solve every governance problem. Accountability runs through the discussion. Jonathan argues that a business remains responsible for the way it deploys technology and approves access, alongside responsibilities held by vendors and model providers. The precise legal allocation will depend on the circumstances. The operational question for listeners is clearer: who owns the use case, who accepted its risks, and who can act when something changes? For teams beginning this work, Jonathan recommends one valuable use case and a reusable implementation pattern. Define the boundaries, test the controls, retain human judgment where needed, and use the experience to inform the next deployment. The conversation offers a practical starting point for organizations trying to gain value from AI agents while keeping their access and actions understandable. Please share your thoughts. How is your organization deciding what AI agents may do, and what would help you keep ownership, permissions, and oversight clear after deployment?
#3778
November 7 · 19 min
Bringing enterprise AI inference on premises with Scality
What should a business consider before moving AI inference onto infrastructure it owns? In this episode of Tech Talks Daily, I speak with Paul Speciale, Chief Marketing Officer at Scality, about the decisions behind enterprise AI infrastructure. Following the launch of Scality AI Inference Factory, we discuss why organizations are assessing on-premises inference alongside cloud services, with attention to costs, model control and the location of sensitive data. Paul expects a hybrid approach, with different workloads running in the environments that suit their requirements. The conversation begins with the work a GPU repeats when an AI session needs to process familiar context. Paul explains how saving and retrieving that information can reduce recomputation, and why storage and networking deserve attention alongside compute. We discuss where the economics change as usage grows and why owning the infrastructure also means taking responsibility for utilization, performance and the operating bill. We then consider data placement across storage tiers. Paul argues that there is no single best location for every workload, with performance, cost and sovereignty requirements shaping the decision. I ask where automation should stop and human approval should begin. He describes automating health checks, forecasts and recommendations while retaining approval for consequential changes such as deleting data or changing policies. Cyber resilience is another part of the discussion. Paul explains why an immutable copy needs to be supported by tested recovery, and why sovereignty rules should be checked through attempts to perform actions the system is meant to refuse. We close with the responsibilities infrastructure teams take on as they manage inference directly, from tracking time to first token and context reuse to deciding when a model should change. For leaders assessing their next AI deployment, the conversation offers practical questions about control and the evidence behind the business case. Which workloads would you consider running locally, and what would you want to prove before making that decision? Please share your thoughts with me.
#3780
November 6 · 20 min
Why AI Agents Need Better Data With Steffen Hoellinger of Confluent
What if many of the problems businesses blame on AI are actually problems with their data? It's a question I wanted to examine when I sat down with Steffen Hoellinger, Field CTO EMEA at Confluent, during Current 2026 in San Francisco. After a year dominated by conversations about AI agents, I'm increasingly interested in the less glamorous work companies need to get right before these technologies can deliver anything useful. Steffen works with enterprises across Europe, helping them manage real-time data and develop AI applications. Our conversation begins with the difficulties businesses face when information is scattered across departments, applications, and different locations. He explains why simply moving data between systems is no longer enough, and how processing, filtering, and preparing information as it moves can help applications make better decisions. We also discuss Confluent's Streamhouse announcement and the growing role of Apache Kafka and Flink. Steffen explains how these technologies help businesses process information closer to where it originates, rather than waiting for scheduled transfers and reports. For companies trying to put AI agents into production, he argues that having the right information available when it is needed can make an enormous difference. One of my favorite moments comes when our conversation turns to where this technology is actually being used. Steffen shares an unexpected example from the America's Cup, where Kafka helped exchange information between a racing yacht and a separate support boat. We also talk about factories and retail stores that can continue operating independently when their connection to the cloud is interrupted. From there, we examine the particular challenges facing European companies. Data sovereignty, privacy, regulation, and concerns about relying too heavily on public cloud infrastructure all influence technology decisions. Steffen explains why open standards and the ability to operate across different environments matter to businesses that cannot afford extended downtime. Another subject I wanted to challenge him on was the amount of money being spent on AI models. Steffen argues that companies shouldn't assume an expensive large language model is the answer to every problem. Traditional machine learning, event processing, and simpler analytical techniques can often perform particular jobs faster and at a lower cost. He explains how businesses can combine those approaches, using AI models only where they offer additional value. We also discuss his experience founding Airy, which Confluent acquired in 2025, and what he's learned about moving from a startup to working with some of the world's largest enterprises. That leads to a wider conversation about governance, accountability, and what happens when organizations begin using large numbers of AI agents across their operations. Steffen makes an interesting point about business processes that have historically depended on people and software working together. Introducing AI agents will require companies to reconsider how those processes operate, while retaining clear human accountability for the decisions being made. Towards the end of our conversation, I ask what European CIOs should prioritize over the next 12 months. His advice is to concentrate on the data companies already control, understand where it comes from, establish consistent schemas and governance, and avoid committing too early to a single AI platform. It's a useful conversation for anyone trying to separate the excitement surrounding AI from the practical work required to make it useful inside a business. As more organizations prepare to introduce AI agents into everyday operations, are we spending too much time choosing models and not enough time understanding the information those models depend on? Listen to our conversation and share your thoughts.
#3779
November 5 · 22 min
Current 2026: Why Confluent's Streamhouse Could Solve AI's Real-Time Data Problem
What happens when an AI agent makes a business decision using information that's already out of date? It's a question I wanted to put to Stephen Deasy, CTO of Confluent, when we met at Current 2026 in San Francisco. After attending more than 20 technology conferences this year, I've heard countless promises about what AI agents will eventually achieve. But there's a growing problem behind those ambitions. Businesses are still struggling to get accurate, current information out of the systems they already own. Confluent has introduced Streamhouse, a data architecture designed to address that problem. Stephen explains why the company believes existing approaches can leave applications working with delayed or incomplete information, and how the new architecture brings streaming, processing, governance, and querying together. We also discuss Lightning Tables, one of Confluent's major announcements at the event, and what direct access to current Kafka data could mean for developers and their businesses. I was particularly interested in what this means for companies that have already invested heavily in data warehouses and lakehouses. Stephen makes the distinction between analyzing past performance and running business operations using current information. He explains why Confluent sees these approaches working together, and why existing technology investments can provide the foundation for introducing Streamhouse. We also discuss the experiences of Instacart and Citizens Bank. Stephen recalls how Instacart faced a sudden increase in demand during the pandemic, when accurate information about orders, inventory, and deliveries became especially important. He also describes how Citizens Bank improved loan fulfillment processes through real-time data streaming. Both examples help explain why the speed at which information moves between business systems can affect customers directly. The conversation also covers IBM's relationship with Confluent, open technologies including Kafka and Flink, and the announcement that Tableflow is now generally available on Google Cloud. Stephen shares his thoughts on model evaluation, human oversight, and how companies should measure returns from their technology spending. One of my final questions concerns the misconceptions surrounding Streamhouse. Stephen explains that the architecture brings together approaches many organizations have already been working toward, and that its value lies partly in making those capabilities easier to use together. With so much money being invested in AI, are businesses paying enough attention to the information those systems depend on? Listen to our conversation and share your thoughts.
#3777
November 4 · 26 min
Electrifying Collection Fleets and Improving Driver Safety With Republic Services
How do you introduce electric vehicles and AI-assisted safety technology into a collection fleet that customers depend on every day? On Tech Talks Daily, I'm joined by Brett Rogers, Vice President of Operations Technology at Republic Services, to discuss the engineering, infrastructure, and human decisions behind modern waste and recycling operations. Brett's background includes work at Toyota, General Motors, and Cruise. He describes arriving from the automotive sector and discovering how much complexity sits behind a service most people expect to happen without thinking about it. We give particular attention to electric refuse trucks. Range is part of the calculation, but the vehicle also powers equipment that lifts containers and handles material. Brett explains how Republic Services models energy use across the chassis and collection body, taking account of terrain, climate, speed, and the work required on a route. The goal is to identify where an electric vehicle can replace a conventional truck while maintaining service. Route selection can produce some surprising answers. A residential truck making frequent stops may benefit from regenerative braking, while a vehicle with fewer container lifts can spend much of its day covering distance. Brett describes why his team began with residential applications, then used operational data to inform expansion into other vehicle types. The number of lifts alone does not tell the whole story. Charging has its own planning cycle. Brett says utility discussions, design, and construction can require decisions roughly two years before trucks are needed. We discuss why depot readiness has to lead vehicle delivery, alongside the arrangements that keep service running if power is interrupted. He describes spare vehicles and equipment that can accept emergency power, while on-site storage and renewable energy form part of the options being considered. These approaches have different levels of maturity, and the conversation keeps that distinction clear. Technology-enabled safety is the other major focus. Brett describes adding a bird's-eye camera view to help drivers see around large vehicles, then working with vendors on systems that distinguish people from objects. Spoken alerts such as "pedestrian rear" are intended to tell a driver what is happening and where, without requiring them to keep checking another screen. The discussion goes beyond installing cameras. Brett says in-cab alerts were associated with an initial reduction of around 20% to 30% in what Republic Services calls unfocused behaviors. He reports a reduction of 95% after coaching was added to the approach. These are company-reported behavioral measures, not a claim that collisions fell by 95%. No evaluation period or underlying methodology is provided in the interview. The useful operational lesson is the connection between technology, explanation, and the opportunity for drivers to correct a recurring behavior. We also discuss employee adoption. Brett recalls drivers who were initially reluctant to move from diesel trucks and describes how time in the electric vehicles changed their view. He points to lower noise, vibration, and heat, alongside cab design. His account is a reminder that the experience of the person doing the job can determine whether a promising deployment becomes a useful everyday tool. We finish with routing visibility for municipal customers and plans to use AI and other tools to improve operations. For fleet leaders, the conversation offers practical considerations around duty cycles, charging resilience, driver support, and measuring results. For everyone else, it reveals the work behind a truck arriving on the right street at the right time. I'd welcome your thoughts. What would give you the most confidence in an electric fleet rollout, and how should organizations demonstrate that their safety technology is helping drivers and communities?
#3776
November 3 · 26 min
Building Trust in Production AI Agents With Caylent.
What would make you comfortable giving an AI agent the authority to act inside a live business process? In this episode of Tech Talks Daily, I speak with Valerie Henderson, CEO of Caylent, about what has to happen between a successful demonstration and a system a business can depend on. The conversation centers on production readiness, including access controls, spending limits, traceability, workflow design, and the people responsible for the outcome. Valerie describes why introducing agents requires changes to how work gets done. If an organization adds new technology without reconsidering the handoffs and decisions around it, the hoped-for productivity gains can remain difficult to achieve. Her advice is to begin with a bounded problem where automating a few steps could provide a clear benefit, then build on the evidence rather than starting with an ambitious network of agents. We discuss the difference between read-only workloads and agents that can alter live systems. Valerie says many customers are already comfortable with agents retrieving information, while autonomous operations such as self-healing infrastructure are concentrated among the most advanced customers she sees. Those observations reflect her experience with Caylent engagements. They do not establish a universal level of enterprise adoption. For me, one of the most useful questions is what meaningful human oversight looks like. Valerie is clear that people remain accountable for the instructions and access they give agents. She emphasizes deliberate testing, appropriate governance, and the ability to understand what a system has done. We also discuss how agents can repeat work without producing anything useful, creating a bill that needs to be considered alongside accuracy and reliability. The conversation moves into Caylent's own operating model. Valerie describes moving away from assumptions built around human time and materials, making existing technical knowledge easier to reuse, and changing delivery incentives to reward speed and customer satisfaction. It is a practical reminder that organizations adopting AI may need to reconsider what they reward as well as which tools they buy. She also shares a customer example involving Smarsh. According to Valerie, redesigning its software delivery process with agentic AI freed engineering capacity that could be reinvested in the business. She describes that capacity in financial terms, but the interview does not establish a measurement period or separate capacity value from realized cash savings. The useful lesson is the connection between a defined objective and a decision about how to use the resulting capacity. We touch on Caylent's agentic AI readiness research, while keeping the broader discussion focused on practical experience. The useful question for leaders is what controls and evidence should come before greater autonomy, and how they will reassess that decision as the system changes. Finally, Valerie explains how she thinks about success for employees as well as customers. She wants technologists to have time for difficult problems and opportunities to develop their skills. She also argues that customers should be able to explain the value of the work they have undertaken. Model performance is part of that assessment, alongside the environment, permissions, costs, and business process in which the agent operates. I would love to hear how your team is making these decisions, so please share your thoughts. Which responsibilities are you ready to delegate to an AI agent, and what evidence would you need before going further? Useful Links Caylent website: https://caylent.com/ Caylent's Agentic AI Readiness survey report: https://caylent.com/blog/agentic-engineering-survey-report
#3775
November 2 · 25 min
Connecting AI Fall Detection With Care Workflows at KamiVision.
What makes an AI fall alert useful to the person who needs help and the team responsible for responding? In this episode of Tech Talks Daily, I speak with Mike Link, chief operating officer at KamiVision, about deploying computer vision in residential care. We discuss the connection between the sensor, the people receiving its notifications, and the decisions that follow. The conversation also looks at privacy, connectivity, false alarms, and why a system that works in a care facility needs further work before it can serve a wide range of homes. Mike describes KamiVision's path from home-security cameras to its KamiCare platform. His account of fall detection involves three stages. A device identifies a possible event, a cloud model filters notifications, and a person reviews a blurred, encrypted clip before an alert reaches the user. The human review is part of the service he describes, so it belongs in any discussion of how the system performs. I ask about the company's 99.5% accuracy claim and what buyers should understand before relying on a number like that. Mike explains the filtering process, but the interview does not establish a test population, a missed-event rate, or a complete statistical definition. His answer is a starting point for further questions about performance across the whole service, rather than proof that a device detects 99.5% of all falls by itself. One of the most useful examples concerns a resident found on the floor. Mike describes how reviewing an event can help staff understand whether someone fell or deliberately lowered themselves because they needed help with a task. That information may lead to a change in a routine or room layout. It is an example of how visual context can inform care, rather than an independently measured claim that the technology prevents injuries. We also discuss the difference between a managed care setting and a home. A residential facility can have relatively consistent room layouts and lighting. Homes introduce furniture, pets, several rooms, and areas outside a sensor's view. Mike talks about investigating other sensing technologies to address those gaps. He presents those ideas as work under consideration, not a set of generally available capabilities. Connectivity is another practical issue. Mike says the version discussed uses Wi-Fi and that a cellular option has been considered. He also explains that the consumer version was being tested with families and was not yet available to purchase at the time of recording. That distinction between an established care-facility offering and a product still being developed matters when assessing where the technology can be used today. Privacy and consent are part of deployment. Mike says facilities obtain consent from residents or an appropriate representative, and he describes the service as focused on event clips rather than live viewing into a room. Those explanations help frame the conversation a buyer should have about access, retention, review, and the information people are agreeing to share. Finally, we discuss the business case. Mike connects the value of event information with staff response, communication with families, and adjustments to care. He also describes possible reporting and risk-identification capabilities that had not been deployed. The interview offers a view of the operational questions involved, without establishing a controlled clinical result or a fully quantified return on investment. I would love to hear your thoughts, so please share your experiences. How should care providers assess whether an AI alert improves the work people do, while respecting the privacy and choices of those receiving care?
#3774
November 1 · 27 min
What Proof of Reserves Can Tell You With LeveX
What can a crypto exchange's proof of reserves establish, and what might still be missing from the picture? On Tech Talks Daily, I'm joined by Harvey Liu, co-founder and CEO of LeveX, to discuss transparency, platform engineering, and the responsibilities that come with operating a centralized exchange. Harvey brings a computer science background, an MBA, and experience in venture capital. Our conversation looks at how becoming a founder changed the questions he asks about growth, spending, product delivery, and customer assets. We begin with the community idea behind LeveX. Harvey recalls meeting other crypto investors and wanting an online environment where people could discuss ideas alongside trading. He describes that as part of the motivation for building the company. The interview also makes clear that some social features remain in development or are planned for a later release. A community vision and a finished product roadmap are different things, and the discussion gives listeners a view of that work in progress. The central technology question is proof of reserves. Harvey explains why a snapshot should be considered in context, including its date, the assets it contains, and the liabilities it may not reveal. He discusses the limitations of relying on a platform's own token and the difficulty of understanding obligations outside the information shown. Publishing reserve information can contribute evidence, but the conversation does not establish that a snapshot alone proves a business is solvent or that customer assets are protected under every condition. We also discuss the engineering approach Harvey says LeveX uses. He describes Merkle-tree verification, user account inclusion, and separating parts of the reporting process from the live trading environment. The challenge is to provide useful information while managing privacy and system load. His explanation is a founder's account of the architecture, rather than an independent technical audit or a live demonstration. From there, the conversation turns to the realities of building the business. Harvey says he underestimated how much product development investment would be needed to compete with larger teams. He also describes the difference between taking a minority investment position and being responsible for the operation itself. Cash flow, customer growth, infrastructure decisions, and the consequences of a failure become immediate concerns rather than topics for a periodic review. Security and AI bring further tradeoffs. Harvey describes security reviews, operational controls, and the ability to suspend certain functions if something appears wrong. He also discusses AI-assisted development and analysis, alongside agents being built to help with order placement. These ideas raise questions about access, authorization, accuracy, and responsibility. The interview does not demonstrate those systems or establish that AI-generated analysis improves trading results. Availability is another part of the discussion. Harvey says LeveX restricts access from jurisdictions including the United States, the United Kingdom, Singapore, and mainland China. He describes licensing work as being in progress, rather than announcing completed authorizations. This episode examines a technology business and its founder's decisions. It does not recommend opening an account or imply the service is available in every listener's location. We close with Harvey's views on decentralized exchanges and plans for additional social features, competitions, and copy trading. These remain company plans as described at recording, without a verified delivery schedule or a promise of financial returns. For listeners interested in platform design and founder accountability, the useful thread is how to question evidence, distinguish current operations from future ambitions, and assess what a company is actually claiming. Please share your thoughts. What should exchanges make easier to understand about their reserves, liabilities, and operating controls so people can assess their claims with greater clarity?
#3773
October 31 · 28 min
Reducing IT Firefighting With ControlUp
What needs to happen before an IT team can trust an AI agent to resolve a problem rather than simply report it? In this episode of Tech Talks Daily, I welcome Jed Ayres, CEO of ControlUp, and Gadi Feldman, Chief Product Officer, to discuss autonomous endpoint management and the practical work behind it. We begin with a familiar problem for enterprise IT teams, plenty of monitoring data and recurring issues that still require investigation, ticket transfers and manual intervention. Jed explains why the aim is to follow an operational problem through to an authorized action and then verify that the issue has been resolved. Gadi describes how specialist agents could bring together expertise across areas such as endpoint management, networking and storage. We discuss the connections those agents need to existing tools and why an understanding of the technology is only part of the job. Agents also need access to company procedures, priorities and knowledge, much as a new member of an IT team needs to learn how the organization works. Gadi explains how configurable human approval and other controls form part of that approach, with teams able to begin with analysis and recommendations before allowing additional actions. Jed shares a CHRISTUS Health example involving an audio driver issue across approximately 900 devices, illustrating the value of seeing a common pattern rather than treating every device as a separate support problem. We also discuss what a useful business case should measure. Alongside the time spent by IT, leaders need to consider the employee's experience of waiting for help or finding a workaround. Device performance and software usage can also inform decisions about equipment replacement and unused licenses. The conversation considers what becomes possible when repetitive work takes less of the team's time, while acknowledging the need to establish trust and define the limits of autonomy. For leaders looking for a starting point, Jed describes ControlUp's seven-day challenge, and Gadi recommends understanding the fleet already in place. Which recurring IT problem would you address first, and what evidence would convince your team that automation was helping? Please share your thoughts with me.
#3772
October 30 · 23 min
Making AI the ERP Interface With NetSuite
When would you trust your ERP system to move from answering a question to carrying out the work? Recording at SuiteWorld in Las Vegas, I spoke with Brian Chess, who leads AI product and technology for Oracle NetSuite, about what that progression looks like in practice. Brian was an early developer when the business was called NetLedger, later left to build a company, and returned with a different perspective on the needs of small and growing businesses. Our conversation focuses on how AI can help people understand their systems, complete unfamiliar tasks, and gradually delegate work without losing control of the process. One of Brian's most useful ideas is AI acting as a teacher. He describes users asking Ask Oracle who has logged into their account, or asking it to explain a script they do not fully understand. The benefit is the answer and the explanation of how to find it. Someone who previously needed help from a colleague can begin to understand a part of the system for themselves. He also shares an example involving NetSuite customer MCNC. When the payroll administrator was unavailable, Brian says a controller who had not been trained on the process used Ask Oracle for guidance. The outcome he describes is straightforward and meaningful: payroll ran on time. It is a customer account from the interview, rather than an independently assessed result, but it illustrates how useful AI assistance can be without requiring a dramatic productivity claim. Financial close provides another practical example. Brian describes starting with the spreadsheet a finance team already uses, modelling that process inside NetSuite, and introducing automation in stages. I recognise the appeal of that approach from my own time supporting month-end and year-end work in IT. Teams need to understand how the process will run, especially when a mistake can affect reporting or the system of record. We discuss how permissions apply as software gains the ability to act. Brian says Ask Oracle operates with the permissions of the user, while an agent receives an assigned role governing its access. He describes a progression from read-only analysis to limited changes as users gain confidence. Human approval remains available for transactions, particularly while teams refine instructions and account for cases they may have missed. Business context and shared knowledge are part of the same discussion. Brian explains how written skills can capture procedures and the intended business outcome, making knowledge available beyond the colleague who usually handles the task. We also talk about accountability. He describes transaction records showing which agent acted and when, together with an activity log. Those records help establish what happened, although they should not be confused with a complete explanation of every internal model decision. The conversation also covers whether to build AI capabilities or use those embedded in a business platform. Brian's answer depends on the role the capability plays in a company's competitive position, the expertise available, and the time it wants to invest. His view of ROI is similarly specific to the business. Comparing vendor contracts with billing records may reveal savings, but the same result does not necessarily transfer to a company with different suppliers and arrangements. We finish with the opportunity Brian sees for smaller businesses that have fewer specialists available. AI assistance may help people undertake work they previously needed a consultant or experienced colleague to explain. The question is how to extend that access while retaining appropriate permissions, review, and responsibility. I would love to hear your thoughts, so please share your experiences. Where would conversational ERP make the biggest difference in your business, and which actions would you still want a person to approve?
#3771
October 29 · 30 min
Turning AI Experiments Into Business Value With Newton
What if the biggest gain from AI comes from reducing the distance between the person who understands a problem and the person building its solution? On Tech Talks Daily, I'm joined by Ben Grinnell, Chief AI and Capabilities Officer at Newton, a strategic delivery consultancy working with private and public sector organizations. Ben's career stretches from an early web consultancy to enterprise technology delivery and today's AI tools. He describes returning from retirement after reading a draft book about vibe coding and realizing he wanted to be part of what came next. What interested me was his practical explanation of how AI can change delivery. When a consultant or business specialist can test an idea while hearing the problem directly, fewer handoffs may mean less lost context and quicker feedback. Ben sees an opportunity to build useful solutions closer to the work. He also warns against confusing a demonstration that looks finished with software that is ready to run reliably. Security, architecture, testing, and maintainability still need people who know which questions to ask. We discuss the relationship between business teams and IT. Employees have been building spreadsheets, macros, and local workarounds for years, so the challenge of technology appearing outside central oversight is familiar. AI changes the speed and scope of that activity. Ben argues for keeping technical expertise close to the business, connecting small projects to existing enterprise investments, and producing value early enough that people want to participate. Trust runs through the conversation. Ben describes a progression from private use of AI assistants to shared agents that appear within a team's existing tools. Visibility can help colleagues understand what is happening, but easier access to company information can also expose old permissions problems. A document that has sat unnoticed on a shared site can become easier to find, making sensible access controls part of adoption rather than an afterthought. One of the more surprising examples concerns legacy modernization. Drawing on his experience with caseworkers using different workarounds, Ben discusses separating a technical platform replacement from changes to how people work. He describes AI-assisted rewriting that preserves existing behavior before a later, more gradual process redesign. The conversation presents this as an approach to consider, rather than a demonstrated deployment or a reason to preserve security defects. We also examine AI measurement. Ben challenges the emphasis on how many roles a company can remove and suggests looking at revenue, client service, profitability, and the repetitive work people no longer have to do. His argument is that the way a program is described affects whether employees support it. Leaders still need evidence that a project works, alongside an understanding of how their success measures influence behavior. We finish with Newton's hands-on AI work, including internal hackathons, model access, and Ben's account of investment in sovereign compute for inference costs and UK data requirements. He makes a useful distinction between giving new users a strong first experience and asking experienced users to improve efficiency. Cost control and adoption need to be considered together. I'd welcome your thoughts. How is your organization measuring AI value, and which small improvement has persuaded people to change the way they work?
October 28 · 18 min
NetSuite Founder on the End of ERP and What Comes Next
What if your ERP system came to you through a conversation, instead of asking you to learn its menus before you could get anything done? Recording at SuiteWorld in Las Vegas, I welcomed Evan Goldberg, founder and executive vice president of NetSuite at Oracle, back to the podcast. We last spoke two years earlier about the company's origins. This time, the discussion centres on his description of AI as the UI and what that could mean for the people using business software every day. Evan describes an ERP experience in which users explain what they want in natural language. One example is adding a dashboard metric by describing the information it should show. If the result is not quite right, the user can explain what needs to change. For me, the useful question is whether that makes software easier to fit around a person's work and how reliably it understands the request. We discuss the knowledge behind those answers. Evan describes SuiteSkills as a way to bring together information about NetSuite and the procedures businesses use within it. He connects that work with consistent answers through NetSuite Next and through external tools using the AI connector service. His ambition is to support the models and ways of working customers choose, while making the information returned from NetSuite dependable. It is a product direction he describes, rather than an independently tested guarantee that every model will behave identically. The conversation then moves from answers to actions. Evan points to order approvals, accruals, and agents looking for exceptions that deserve attention. He argues for beginning with a process people already want to improve and deciding which parts can run with human approval or greater autonomy. The appropriate balance will depend on the company and the work involved. A conversational interface does not remove the need to decide where authority belongs. Personalisation is another part of adoption. Evan's view is that people are more likely to keep using an AI feature when they can explain how they want it to work. The dashboard example makes that concrete, but it also raises a wider question about how companies maintain consistent procedures while allowing people to adapt their tools. We also discuss smaller businesses and the opportunity to access capabilities without building a large specialist team. Evan describes a startup offering and his belief that the same AI models can help companies of different sizes. The practical considerations still include eligibility, the work a team needs to accomplish, and the controls around its business information. For partners, he sees an opportunity to make industry expertise available through reusable skills. A specialist's knowledge of a particular niche could inform how Ask Oracle helps customers, while the partner spends time developing that expertise further. It is an interesting view of how advice and software configuration may change as AI becomes part of delivery. I also ask about software pricing. If agents complete tasks that once required someone to log in, what happens to the traditional per-user model? Evan acknowledges the question but offers a counterpoint: easier access to information and personal agents could encourage people to remain users. He does not announce a pricing change, leaving us with a business-model question that is still developing. We finish with an unexpected customer conversation at Disneyland, which Evan uses to illustrate interest from everyday business users. It is a memorable anecdote rather than a measure of adoption, but it brings the discussion back to the people who ultimately decide whether these features earn a place in their working day. I would love to hear your thoughts, so please share your experiences. If AI becomes the interface to your business systems, what would you want it to understand before you let it act on your behalf?
October 28 · 26 min
Giving Enterprise AI Agents the Business Context They Need With SAP
What needs to happen before AI agents can reliably complete work across the systems that run a business? In this episode of Tech Talks Daily, I welcome back Irfan Khan, Chief Product Officer for SAP Data & Analytics, to discuss the distance between a useful AI pilot and a dependable operational workflow. Our conversation begins with the autonomous enterprise and what that means for teams working across finance, procurement, supply chain and HR. Irfan explains why agents need a shared understanding of business activity, including the state of purchase orders and inventory, before coordination can produce a useful result. We discuss the data quality, permissions and governance questions that become harder to manage as deployments grow. Irfan also considers how leaders should measure AI performance. Generating additional content or consuming additional tokens tells us something about activity, but leaders still need to understand the effect on productivity, accuracy and the cost of completing work. He shares how SAP has approached developer experimentation and why teams need to become deliberate about which tasks benefit from AI consumption. The conversation also covers company memory, an initiative Irfan describes as a way to bring institutional process knowledge into agent workflows. We discuss how employee trust depends on the task, why order entry requires a different level of precision from a forecast, and how open architecture can preserve choices as models and infrastructure develop. Irfan then explains SAP's approach to connecting SAP and non-SAP data through SAP Business Data Cloud and the wider SAP Business AI Platform. For leaders assessing the next stage of their AI programs, the discussion offers practical questions about context, access, cost and the business outcomes they want to improve. You can find the resources discussed in the accompanying show notes at TechTalksNetwork.com. Where is your organization finding the biggest obstacle to operational AI, and what would help you move forward?
#3768
October 27 · 28 min
Putting Engineering Judgment to Work With AI and Southworks
When AI makes writing code faster, how do you decide whether your team is building the right thing? In this episode of Tech Talks Daily, I speak with Johnny Halife, CTO at Southworks, about what happens to software engineering when code generation becomes easier but decisions still require experience. The pressure to deliver faster is familiar. The harder question is whether teams have the review capacity, testing processes, and deployment infrastructure to turn that extra output into useful software. Johnny describes a different way of directing AI coding agents. Engineers need to specify the outcome, define what finished work should look like, and provide checks that can show whether it meets the required standard. Constantly telling an assistant what to do next can keep a person busy without giving the system enough responsibility to complete a coherent piece of work. We discuss how to create tasks that are small enough to review and substantial enough to delegate. We also talk about context. Giving an AI system access to institutional knowledge sounds sensible, but adding every document to every conversation creates its own problems. Johnny describes borrowing from open source contribution practices, including README files, contribution guidelines, and records of architectural decisions. His approach combines an explanation of why the system works as it does with directions for finding additional information when needed. It is a useful way to think about onboarding an agent without expecting it to absorb the entire history of a business at once. The phrase human in the loop comes up frequently in AI discussions, so I ask what it should mean in practice. Johnny describes checks before work begins and a review of test results and other evidence at the end, supported by progress updates along the way. The person responsible needs to set expectations and assess the outcome. Being available for an alert is only one part of that responsibility. An unnamed streaming platform project provides a practical example. Johnny explains how Southworks developed the supporting process in stages, improving documentation, tests, and the infrastructure around the developer workflow. He reports a tenfold increase across requests, changes, and delivered value, although we do not have an independently verified measure or a detailed breakdown. His broader observation is that the same improvements made the environment easier for human engineers to understand and work in. Finally, we discuss hiring and professional development. Johnny values software and cloud knowledge, curiosity, clear writing, time management, and the judgment to choose between competing possibilities. AI can make experimentation quicker, but someone still needs to decide which experiment deserves attention and when to stop. I would love to hear how this compares with your own experience, so please share your thoughts. Where does work now wait in your engineering team, and how are you helping people make better decisions about what to build?
#3767
October 26 · 20 min
Understanding the Infrastructure Behind Stablecoin Payments With Noah
What happens behind the scenes when a cross-border payment uses stablecoins, and how much of that should the customer need to understand? In this episode of Tech Talks Daily, I speak with Shah Ramezani, co-founder and CEO of Noah, about the infrastructure that connects stablecoins to business payments. The discussion goes beyond the transfer itself to the practical work required to move between currencies, choose a route, verify identities, and reconcile the result. Shah starts with the friction he sees in correspondent banking and the opportunity for a different settlement layer. He explains how stablecoins can move quickly between participants and then connect to local payment methods at either end. His example of a payment from the United States to Argentina helps explain the choices involved, including whether the recipient wants local currency or a dollar-denominated stablecoin. It is an illustrative scenario rather than a named customer case or a universal comparison of costs and delivery times. I ask what makes that experience work technically. Shah breaks the process into liquidity, routing, compliance, settlement, and reconciliation. The available partner, customer type, destination, and pricing can all affect how a payment is handled. Noah's role, as he describes it, is to bring those components together so partners can connect without building every part themselves. Identity is another part of the conversation. Shah discusses know-your-customer and know-your-business checks, including arrangements in which partners rely on checks performed by Noah and receive the information they need. His account makes clear that reducing repeated document requests requires coordination among the organizations involved. It also raises questions about who is responsible for each step and how that responsibility changes across markets. One idea I found most interesting is that users may encounter stablecoin infrastructure without choosing to hold or handle stablecoins themselves. Shah describes payments in which the technology operates behind a familiar interface. For a business considering that approach, the useful comparison is the full payment journey, including conversion, local payout, support, and each participant's obligations. We also discuss banks' continuing role. Shah rejects the idea that they disappear and instead describes a different distribution of responsibilities across payment networks and financial institutions. The conversation gives listeners a way to consider how new settlement technology can coexist with established banking relationships. Trust and regulation remain part of that assessment. Shah argues that stronger regulation provides reassurance, while acknowledging the difficulty of serving customers across jurisdictions with different reporting obligations, identity requirements, and fraud patterns. His confidence in the market's direction is his perspective. It should not be read as a guarantee that every stablecoin, provider, or transaction carries the same protections. Finally, Shah discusses Noah's plans to broaden its capabilities and invest in product development and hiring. He describes an opportunity to make the payment experience simpler and less complex for the user. For me, the accompanying question is how providers make their responsibilities clear when the underlying process spans several organizations. I would love to hear your thoughts, so please share your experiences. When you assess a new payment route, how do you weigh speed and cost against clarity about responsibility, access to funds, and help when something goes wrong?

Showing 1–20 of 94 episodes