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?

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?

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.

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?

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?

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?

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?

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?

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?

What happens when the pressure to complete an ERP transformation leaves access governance waiting until after go-live? In this episode of Tech Talks Daily, I speak with Chris Radkowski, GRC Expert and Advisor at Pathlock, about the business consequences of access decisions. Chris previously spent 17 years at SAP and brings experience across access control, governance and security. We discuss why ERP risk belongs in transformation planning, with examples that connect system availability to manufacturing, incoming deliveries and the processes that keep a business operating. The conversation considers privileged access inside business applications. An identity does not need to administer a server to hold permissions that affect sensitive information, supplier records or financial transactions.  Chris explains why the combinations of entitlements assigned to a person deserve attention, and how that assessment becomes more complicated as processes extend across several systems. AI agents and automated workflows add to the challenge when they can carry out transactions quickly or operate through credentials associated with a user. We also discuss the limits of scheduled access reviews. Chris describes the work involved in checking whether an inappropriate permission was used, including the manual effort that can arise when teams need to investigate historical transactions. He argues for combining access information with activity and transaction data, so teams can examine an unexpected pattern and initiate a review rather than waiting for the next certification cycle. For leaders planning an ERP or AI transformation, Chris recommends considering role design, access assignment, certification and emergency access early in the program. We discuss how changes between SAP ECC and S/4HANA can affect the permissions and transactions on which existing controls depend. Our conversation offers practical questions about who can act, what they actually do and how the organization responds when operations are under pressure.  Which access decisions would you want resolved before your next go-live, and where are the gaps today? Please share your thoughts with me.