Tech Talks Daily

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?

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?

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?

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?

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.