Tech Talks Daily

What prevents a successful AI experiment from becoming a dependable production system that delivers measurable business value?
In this episode of Tech Talks Daily, I speak with Ed Macosky, Chief Product and Technology Officer at Boomi, about AI pilot purgatory, integration, governance, model selection, token costs, and the technical skills businesses may need as adoption grows.
Ed leads Boomi's product and engineering teams while also using AI tools inside his own organization. That gives him a view from both sides: creating technology for enterprise customers and applying it within active product development workflows.
He believes many AI pilots begin with the wrong question. Teams become interested in the latest model or feature before defining the business problem they want to solve. The experiment may work during a demonstration, then fail when it encounters real data, access controls, security policies, and production systems.
Placing company information inside a data lake and adding a language model does not automatically create a business application. The system must access current data reliably, respect employee permissions, connect with existing applications, and operate within governance rules that security teams can approve.
Ed recommends beginning with a defined business opportunity and establishing the access required to support it. Existing APIs can already provide authentication, permissions, and governance. MCP can offer another route into enterprise systems, but those connections still require security, monitoring, and management.
Team alignment also matters. An AI center may be racing to test models while an integration center concentrates on a different set of priorities. When those groups fail to coordinate, the pilot lacks the connectivity and automation required to become part of a production workflow.
The discussion then turns toward fragmentation. Every technology wave produces new vendors, frameworks, and specialist tools. Early experimentation benefits from variety, but mature companies can eventually find themselves maintaining a complicated collection of products held together with custom code and, occasionally, the digital equivalent of duct tape.
Ed does not recommend placing every function with one provider. He does argue for enough consolidation and abstraction to prevent experimentation from creating years of technology debt. Governance and observability should also work horizontally across different environments, including platforms such as SAP, Salesforce, and several AI model providers.
That becomes increasingly important as businesses introduce autonomous agents. Leaders need to know which agents exist, what systems they can access, what actions they can take, and how each decision is recorded. AI gateways and agent control towers can provide a wider view across otherwise separate technology environments.
Ed also introduces the idea of the frontier engineer. A prompt engineer concentrates on communicating effectively with a model. A frontier engineer understands how the model works, including its logic, mathematics, algorithms, and suitability for different workloads.
He does not believe every company needs a large team of these specialists. However, he argues that enterprises need at least one person capable of assessing vendor claims and deciding whether a frontier model, specialist model, or open weight model fits a particular workload.
Cost creates another reason to examine model selection. Sending every employee request or agent task to the most capable frontier model can become expensive. Some repeatable workloads may run on open weight models inside the company's cloud or hardware environment, giving finance teams greater cost certainty.
Boomi is developing Boomi Prompt to route requests according to their complexity and requirements. A simple factual request might go directly to an API. A forecasting task may use a smaller model. A difficult analytical request could be sent to a frontier model.
Ed uses the weather as a helpful example. Retrieving next Tuesday's forecast does not require a language model when a public weather API can return the answer directly. Asking a model to perform every form of automation wastes tokens, computing power, energy, and money.
The episode closes with practical advice for CIOs. Avoid starting with a broad objective such as agentifying the entire business. Choose a department, identify a small number of tasks, define the expected return, and work backward. Once the team proves value and understands the operating requirements, it can repeat the process elsewhere.
Could intelligent routing, stronger integration, and clearer business outcomes finally move enterprise AI beyond pilot purgatory? Listen to the episode and share your thoughts with me.

What must happen before a business can trust AI agents to detect and resolve operational problems without waiting for human intervention?
In this episode of Tech Talks Daily, I speak with Josh Clay, Regional Vice President of Solution Engineering for Dynatrace in the UK, about autonomous operations, AI observability, fragmented telemetry, business outcomes, and the growing pressure to control token and data costs.
Josh has spent much of his 11 years at Dynatrace discussing the road toward autonomous operations. The earliest version involved reducing the time organizations spent inside IT war rooms. He remembers calls with 30 or 40 people attempting to establish which team was responsible for an incident. He jokingly calls this the "mean time to innocence."
Modern observability reduced many of those investigations from several hours to between 30 and 60 minutes. Agentic AI creates the possibility of going further by identifying a problem, understanding its cause, and resolving it before the customer experience is affected.
That ambition also introduces risk. Josh cites Dynatrace research showing that 52% of respondents view security, privacy, and compliance concerns as barriers to AI adoption. He believes many organizations still lack full observability across their existing technology environments, making autonomous agents harder to supervise.
Josh shares a warning from Alex Hibbert of Storia Group: AI can amplify existing technology problems. If telemetry is fragmented, data quality is poor, or teams cannot see how services depend on one another, adding autonomous agents may increase the speed and scale of the resulting failure.
Trust therefore depends on visibility. Josh describes observability as a control plane for agentic AI because it can show what an agent is doing, why it made a decision, and what happened afterward. Defined guardrails and real time information can give leaders confidence without asking them to surrender control blindly.
The adoption figures show how early this work remains. Josh says 50% of businesses have AI operating in limited production use cases, often performing one isolated task. Only 23% describe their deployments as connected across the wider organization.
We discuss how observability has progressed beyond technical monitoring. An airport can measure whether technology changes improve e-gate availability and passenger processing times. A bank can examine whether application performance affects mortgage completion rates. These connections allow leaders to measure AI through business results rather than relying entirely on response times and infrastructure metrics.
Reliable agents also need suitable data. Dynatrace says AI agents operating with deterministic data can work 12 times more accurately and three times faster while using two and a half times fewer tokens. These remain company findings, but they demonstrate why context and causality can affect cost as well as reliability.
Fragmented telemetry creates another barrier. Logs may sit in one platform, front end monitoring in another, and metrics or traces somewhere else. Attempting to reconstruct every relationship for an AI agent can become expensive and difficult.
Josh recommends bringing observability data into a connected environment where relationships between services, cloud resources, traces, metrics, and logs are already understood. He also warns against collecting information simply because it exists. Data hoarding increases ingestion costs and can introduce personal information into systems without a clear business need.
The conversation then moves toward AI FinOps. Leaders want to know what agents cost, how many tokens they consume, and whether those costs produce a measurable return. Josh describes a Dynatrace proof of concept that identified potential annual savings just below £250,000 within one small environment.
That example reinforces a recurring concern. Organizations are racing to place AI into production, then moving to the next project without reviewing whether the previous environment is appropriately sized or financially efficient.
Josh hopes companies will develop a more pragmatic view of AI as another enterprise tool. That means establishing agreed methods for deployment, monitoring, cost management, incident response, and measuring business results.
Could observability provide the confidence businesses need to move from isolated AI experiments toward autonomous operations? Listen to the episode and share your thoughts with me.

How can businesses secure AI agents that read sensitive information, update systems and communicate with other agents on behalf of employees?
In this episode of Tech Talks Daily, I speak with Sachin Nayyar, founder and CEO of Saviynt, about AI agent identity security and the controls businesses need before autonomous systems enter production.
Saviynt manages over 100 million identities for over 700 customers. Sachin explains how enterprise identity has expanded beyond employees to include partners, applications, machines and autonomous AI agents.
An AI agent creates a different access problem because it is both an identity and an application. It can receive permissions, access information and perform actions, but its behavior can also be governed through software while it is being developed and while it is operating.
Sachin uses an HR copilot to demonstrate why context matters. Two employees can ask the same question about salaries but should receive different answers based on their roles, locations and applicable policies. Those decisions must be evaluated while the request is being processed without creating delays that make the system unusable.
The risk grows when an agent crosses from one technology environment into another. An agent built within Microsoft may need to access Salesforce, ServiceNow, Jira or another external system. Sachin warns businesses never to solve this problem by giving an agent a permanent administrative account.
We discuss Zuma, Saviynt's identity security platform for AI agents and non-human identities. Sachin describes a four-part framework beginning with agent discovery and a central registry. Every agent should then receive one accountable human owner, temporary access for its assigned task and policy enforcement while it acts.
Ownership becomes especially important when an employee leaves. Saviynt's approach begins an automated reassignment process and blocks actions if an agent attempts to operate without a current owner. The relevant security team can then investigate before allowing further activity.
Sachin also explains why identity controls should enter the development process rather than being added after deployment. Saviynt is working with LangChain and other agent development platforms to make identity policies available while AI agents are being built.
The conversation also covers Saviynt's partnership with Zscaler. Zscaler provides inline enforcement, while Saviynt contributes identity information about the agent, its owner, existing permissions and expected behavior.
Sachin closes with an optimistic argument. Because businesses can place security controls into the code and enforce them while agents act, AI workloads may eventually become better governed than traditional human access.
Could every AI agent inside your business be traced to one accountable owner, one approved purpose and a limited set of temporary permissions? Please share your thoughts with me.

What becomes possible when enterprise computer vision no longer depends on expensive GPU infrastructure?
In this episode of Tech Talks Daily, I speak with Glenn Jocher, founder and CEO of Ultralytics, about YOLO26, CPU inference, edge AI, open vocabulary vision, deployment economics, and the practical work required to move computer vision from a promising pilot into production.
Glenn's route into AI began inside the U.S. intelligence community. He worked with the National Geospatial Intelligence Agency and Defense Intelligence Agency on particle physics applications, attempting to detect and track antineutrinos.
Antineutrinos are extraordinarily difficult to detect because they pass through almost everything. Glenn describes them as the perfect spy. While searching for better detection methods, he discovered that computer vision researchers were solving similar problems with images.
His original attempt to transfer those techniques into particle physics did not succeed. However, the work introduced him to a field where the technology could create a visible effect on everyday life. That led him toward open source development and eventually the YOLO models for object detection, classification, segmentation, and tracking.
Glenn believes computer vision research has historically placed too much attention on small gains in accuracy while overlooking deployment economics. A model can perform impressively inside a laboratory and still remain unsuitable for a factory, warehouse, store, vehicle, drone, or medical environment.
Price, latency, power consumption, data privacy, and deployment speed can determine whether the technology is commercially useful. This led Glenn and Ultralytics toward smaller models capable of running close to where images and video are generated.
YOLO26 continues that approach with architectural changes designed specifically for CPU inference. Glenn says the model can process camera streams in real time at 30 frames per second and run across Intel CPUs, AMD CPUs, and lower power devices such as Raspberry Pi computers.
This matters because specialist GPUs can increase the equipment cost and power requirements of a computer vision project. Running inference on existing CPUs or edge hardware can make deployment economically possible across larger numbers of cameras and locations.
The scale already involved is difficult to comprehend. Glenn says Ultralytics models now process approximately three billion inference jobs each day, equivalent to around 30,000 every second. These jobs include images, videos, and collections of images being analyzed to detect, segment, or track objects.
He attributes the platform's maturity to thousands of mistakes and bugs corrected through a rapid feedback cycle. New models are released, users report problems and request features, and the team incorporates that information into later versions.
We also discuss the respective roles of cloud and edge infrastructure. Glenn sees cloud platforms continuing to provide the computing power required for training, while computer vision inference often belongs at the edge. Local processing can reduce latency, control operating costs, and keep sensitive video or medical information closer to where it was created.
The smallest YOLO model is approximately three megabytes, according to Glenn. That allows it to reach mobile phones, vehicles, drones, battery powered devices, and other environments where a large language model would be impractical.
Open vocabulary vision provides another development. Traditional object detection models are trained to recognize a fixed collection of objects. If a model learns to detect dogs and the user later wants it to detect cats, retraining can cause it to forget earlier knowledge unless both categories appear in the new training data.
Glenn explains how promptable models can identify common everyday objects from text or visual instructions without additional training. A user could request a person wearing a blue shirt and white shoes, for example, and the system could search an image for that description.
That flexibility could benefit businesses whose requirements change regularly. It reduces the need to create and label a new data set every time the company wants the model to recognize another common object.
The range of current applications is already extensive. Glenn describes YOLO being used across robotics, parking, industrial safety, PPE detection, warehouses, aviation, security, traffic management, food quality, and manufacturing.
Some of his favorite examples involve environmental problems. One company uses YOLO with underwater vehicles to identify and recover plastic from the ocean. Other applications detect smoke and fire early enough to support forest fire response.
For leaders considering computer vision, Glenn recommends beginning with a defined problem and measurable outcome. A manufacturing company may want to reduce defects, but it still needs labeled examples showing the model what acceptable and defective products look like.
He advises testing the idea through a limited pilot, measuring the return, and expanding only when the evidence supports further investment. Computer vision has become easier to deploy, but practical problems involving data, cameras, integration, reliability, and operating conditions still separate a demonstration from a production system.
Could CPU inference and open vocabulary models make computer vision practical for processes your organization previously considered too expensive? Listen to the episode and share your thoughts with me.
Useful Links
 
Ultralytics website
Ultralytics Platform

What can private companies learn from government caseworkers about adopting automation and using data more effectively?
In this episode of Tech Talks Daily, I speak with David Turner, General Manager and Senior Vice President of Government Services at Equifax Workforce Solutions, about public sector automation, data modernization, and the people responsible for delivering social services.
The conversation begins with a surprising finding from an Equifax Government Services study of over 500 U.S. government employees. Every respondent expected efficiency to improve during the following year, while 95% believed automation would free time for higher value, human centered work.
David explains why government employees may be more receptive to modernization than many people assume. Caseworkers operate under rising demand, staffing pressures, changing policy, and limited budgets. When technology removes repetitive administration or supplies information faster, they can see an immediate connection between the tool and the person waiting for support.
We discuss how the meaning of automation has changed inside social services. A few years ago, it might have meant entering information into an online portal. Today, integrated connections can search data sources behind the scenes and return verified information during the caseworker's existing process.
David describes continuous evaluation, which can identify when circumstances within a caseload have changed. Instead of searching every case for a possible update, a worker can direct attention toward the people whose income, address, or employment data indicates that further review may be needed.
Income verification provides another example. Equifax says it can return income information in under one second, helping prevent the delays created when an applicant must leave the process to find a document. Those pauses matter when an eligibility decision already involves several stages and numerous external systems.
The gig economy makes this work harder. Applicants may receive income from employment, contract work, digital platforms, and several side projects. Agencies need access to a fuller income picture without sending people back toward paper forms and manual verification.
David also shares what Equifax has learned through its Day in the Life program. The team spends time with caseworkers to understand their processes, policy restrictions, and information constraints. He believes public sector leadership can remain closely connected to employees in the field because many agency executives previously performed those roles themselves.
AI introduces further possibilities. David discusses how data and AI could eventually identify signs that someone who has left an assistance program may be experiencing financial difficulty again. Community groups, food banks, or other services could potentially offer support before that person returns to crisis. Such a system would also require careful decisions around consent, privacy, accuracy, and responsibility.
The central lesson is refreshingly human. Technology creates value when it removes administrative pauses and gives experienced caseworkers additional time to understand someone's circumstances.
Could public sector automation teach private companies how to connect technology investment with human outcomes? Listen to the episode and share your thoughts with me.