Spotify Brings Back Running Music With More Control and Less Sensing
Running Mode builds structured workouts from tempo and taste, but runners must choose the pace instead of having it detected automatically.
Spotify has launched Running Mode, a new Premium feature that turns music playlists into structured running sessions. It combines a chosen workout style, duration, musical taste and tempo with optional spoken cues.
The feature began rolling out on July 30 through Spotify’s Fitness Hub. It is initially available on iOS in the United States, Canada, the United Kingdom, Ireland, Australia, New Zealand and Sweden.
Users start with one of 25 presets, then select a workout type such as a steady, interval or pyramid run. They can adjust the duration and beats per minute, commonly shortened to BPM, which describes the tempo of the music. Spotify then selects personalized tracks, matches them to the chosen tempo and moves between songs as the session progresses.
Optional English audio cues can mark stages of the run and provide encouragement. Spotify says fitness requests have been among the most common uses of Prompted Playlists, its system for creating playlists from natural-language instructions.
Running Mode is part playlist generator and part lightweight workout guide. The structured presets and spoken cues bring planning that runners would normally get from a separate fitness app into the music service.
It is not, however, a system that continuously listens to a runner’s body or automatically adjusts when the person speeds up. The Verge and other independent reports note that users must choose their desired tempo in advance.
That distinction matters because Spotify has tried a more sensor-driven version before. Its original Spotify Running feature, introduced in 2015 and retired in 2018, used phone hardware to detect pace and select music that matched it. The new product asks the user to describe the intended session instead.
This makes Running Mode more predictable but less responsive. A runner can deliberately build a 30-minute interval workout around a specific BPM. If fatigue, terrain or weather changes the real pace, the music will not necessarily adapt with it.
Spotify has been expanding from passive listening into activity-specific experiences. Its Fitness Hub already includes Peloton classes and creator workouts. Running Mode adds a format that can keep the music itself at the center while giving subscribers another reason to remain inside Spotify during exercise.
The launch also follows Strava’s removal of Spotify controls from its recording interface. Running Mode does not replace a full tracking service, but it gives runners a more complete session without relying on integration with another app.
For listeners, the practical value is convenience. Choosing music by BPM manually can take time, and a badly timed song change can disrupt an interval. Spotify can use listening history to make those choices more personal than a generic workout playlist.
The uncertainties are mostly about reach and performance. Spotify has not announced Android availability or a broader country rollout. Audio cues are English-only, and the company has not published evidence showing that the feature improves pace, motivation or retention.
The useful way to see Running Mode is therefore modest. It is not an automatic coach that understands the runner in real time. It is a personalized soundtrack with a workout structure attached. For many casual runners, that may be exactly enough.
When the Browser Starts Acting on Your Behalf
Gemini Spark’s Chrome integration shows why the next browser habit may be reviewing actions rather than clicking every step.
For most of its history, a web browser has been a tool for direct manipulation. You choose a page, click a link, type into a field and approve the result. Even when websites automate work, the browser mainly carries out a visible sequence of human decisions.
Google’s latest Gemini Spark update points toward a different relationship. Announced on July 30, the personal AI agent can now use Chrome, with permission, to work through online errands using a person’s logged-in accounts and saved credentials. Google’s examples include arranging apartment viewings and researching flights before handing the booking process back to the user.
Spark itself is not new. Google introduced the background agent in May and designed it to connect with services such as Gmail, Calendar, Drive, Docs and Sheets. It can run tasks and schedules in the cloud even while a user’s devices are off. The new Chrome integration is significant because it brings that persistence into the authenticated web.
The browser is no longer only where a person acts. It is becoming a place where a person delegates.
An agent needs context to be useful. A flight search improves when it knows a traveler’s dates, preferences and loyalty accounts. Scheduling an apartment viewing becomes easier when it can use saved listings, email and calendar availability.
That same context makes mistakes more consequential. A chatbot that recommends the wrong flight has produced a bad answer. An agent that fills forms, navigates accounts and prepares a transaction has moved closer to producing a bad outcome.
Google says Spark requires permission to use logged-in accounts and saved passwords. The model does not directly read stored passwords. Chrome can ask for confirmation before signing in, and payments or other sensitive actions are supposed to return control to the user. A work log shows the steps taken, and the task can be paused or stopped.
Those protections reveal the real design problem. The important boundary is not whether an agent can click. It is when access becomes authority.
Saved credentials traditionally remove the friction of typing a password. In an agentic browser, they also make it possible for software to enter an authenticated environment on the user’s behalf. The practical question becomes which sites the agent may read, which it may change and which decisions must always wait for a person.
The open web was built for people and software, but not for language models that treat page content as instructions and context. That creates a threat called indirect prompt injection. Malicious or manipulated content on a webpage can try to redirect an agent, reveal information or trigger an unwanted action.
Google’s Chrome security team describes a layered response. A separate model checks whether proposed actions match the user’s goal. The browser limits the web origins the agent can read from or write to. Sensitive steps require confirmation, while threat classifiers scan pages for attempts to influence the agent.
This is meaningful engineering, not proof that the problem is solved. Google explicitly says its prompt-injection detector cannot catch everything and describes browser-agent security as an emerging field. The company has also opened its vulnerability reward program to relevant agentic security failures.
Independent reports from 9to5Google and Thurrott confirm that Chrome auto browse uses local logged-in sessions, pauses for payments and is initially rolling out in the United States. Spark access is expanding to Google AI Pro subscribers in more than 160 additional countries, but feature availability and subscription requirements vary.
What remains uncertain is how the safeguards perform across the messy long tail of websites, embedded content, redirects and unusual checkout flows. Google has described its architecture, but the public announcement does not provide a broad real-world failure rate.
The immediate temptation is to judge an agent by how much time it saves. A better measure is how clearly it defines responsibility.
Low-consequence research is a sensible starting point. Comparing flight options, collecting public information or preparing a shortlist can be inspected before anything changes. Tasks involving messages, account settings, purchases or sensitive records deserve narrower permission and an explicit handoff.
Users will also need to review process, not just outcome. If an agent returns three apartment appointments, it matters which sites it visited, what information it submitted and whether it accepted any terms along the way. A plausible result can conceal an inappropriate route.
The useful missing angle is that supervision does not mean watching every automated click. That would erase much of the benefit. It means designing checkpoints around consequences. Search can proceed in the background. Commitments, disclosures and irreversible actions should remain legible and deliberate.
The shift may eventually change browser interfaces. History pages record where a person went. Agent logs must explain what software did, under which instruction, with what data and where it stopped. Permission settings must become understandable as task boundaries rather than a long list of technical access switches.
Gemini Spark’s Chrome integration is an early version of that future, not its final form. Its value will depend less on whether it can complete an errand than on whether people can confidently understand the authority they handed over. The next browser skill may not be faster navigation. It may be knowing when not to delegate.
AI Use Is Outrunning Workplace Training
A new global study suggests many employers are teaching basic tool use while leaving workflow redesign and reskilling for later.
Companies have spent the past few years buying access to artificial intelligence. A new study suggests many have not made the matching investment in how people should use it.
Research released by The Conference Board on July 28 found that 55.1 percent of surveyed workers use generative AI or AI agents daily or weekly. Only 33.3 percent had participated in employer-provided AI training during the previous six months. More than a quarter said their organization offered no AI training at all.
The findings come from interviews with 35 enterprise leaders and a global survey of nearly 1,300 workers. They do not prove that every workplace has the same gap. The public summary does not provide enough demographic detail to treat the sample as a universal measure. It does, however, identify a practical problem that businesses can test inside their own operations.
AI adoption can spread through individual experimentation. Reliable business use cannot.
Many workplace programs still concentrate on AI literacy and basic prompting. Those skills help employees understand what a generative model can do and how to ask it for a useful response. They are a reasonable starting point, but they do not prepare a team to redesign a process around the technology.
Applied capability is more demanding. A worker using an AI agent, which is software that can carry out a sequence of actions toward a goal, needs to decide what the system may access, where a person must approve its work and how failures will be detected. Someone integrating AI into customer support must understand escalation, privacy, record keeping and quality checks, not only how to phrase a request.
The Conference Board found that fewer organizations were developing skills such as managing agents, integrating AI into workflows and applying it to strategic business problems. Independent coverage from HR Dive and Learning News highlighted the same distinction between introductory training and preparation for changing roles.
This matters because a license can be counted immediately while capability is slower and harder to measure. A company can report that thousands of employees have access to an assistant even if most use it for occasional summaries. That is different from changing how a sales proposal is prepared, how maintenance is scheduled or how an insurance claim is reviewed.
Federal Reserve research offers useful context. Its review of several US surveys found that estimates of workplace AI adoption vary widely depending on who is asked and how the question is framed. At the end of 2025, one survey estimated that 18 percent of firms had adopted AI, while an individual survey put work-related generative AI use at about 41 percent of the labor force. The difference is a warning against equating employee experimentation with material operational adoption.
Only 48 percent of workers in The Conference Board survey said their employer provided enough work time to build AI skills. A similar share said they had sufficient tools, access and resources.
That finding exposes a common accounting error. Training is often treated as a course to purchase rather than work that requires capacity. If employees are expected to learn through experimentation after completing their normal workload, the organization is shifting the cost onto them and making progress dependent on personal time and confidence.
The study’s enterprise leaders emphasized hands-on experience and managerial support. That points toward a different model. Teams need protected time to test a real task, compare the result with the existing process, document failure cases and decide whether the change is worth keeping.
The most useful unit is not a generic AI workshop. It is a supervised workflow experiment. A finance team might test invoice classification on historical data. A marketing team might compare research briefs produced with and without an assistant. A service team might measure whether suggested replies reduce handling time without lowering accuracy or customer satisfaction.
Each experiment should have an owner, a narrow business outcome and a review point. It should also record what employees had to learn beyond the tool itself. Those adjacent skills, including evaluation, data handling and exception management, are often where the real training requirement appears.
The study argues that most employers are improving skills for current roles while doing less to prepare people for roles that will change substantially. That does not mean companies should predict exactly which jobs will disappear or emerge. Such forecasts remain uncertain.
It does mean workforce planning should begin before a tool is deployed at scale. If an agent takes over the first draft of a task, the human role may move toward verification, judgment and handling unusual cases. Those responsibilities need to be designed, taught and rewarded. Otherwise, a company may automate the visible step while leaving workers responsible for an undocumented layer of correction.
The missing angle in many discussions of AI training is that the goal is not tool fluency. It is organizational reliability. Businesses should measure whether employees can recognize weak output, intervene safely and improve a process over time.
The practical consequence is straightforward. Before buying another block of AI licenses, leaders should examine a few high-volume workflows and ask whether staff have the time, access and authority to learn how those workflows should change. If the answer is no, the constraint is not the model. It is the operating system around the people using it.