| |
|
| |
| |
| |
|
Our selection of the top business news sources on the web. |
| |
| |
| |
Global Advisors News Brief - October 14 2026Read the full brief at the link Headlines for the last 24hrs
Time window: 2026-10-13T03:30:33.081Z to 2026-10-14T03:30:33.081Z |
| |
| |
Quote: Andrej Karpathy - AI guru, Anthropic"This is the weirdness of the moment. The general public has mostly not interacted with [AI]. When they have, it looks like a derpy chatbot. The majority of professionals still see only a modest uplift. And a small sliver of professionals are experiencing the vertigo of the curve going vertical. And it is all happening at the same time." - Andrej Karpathy - AI guru, Anthropic The defining problem is not simply whether artificial intelligence works. It is that different groups are forming radically different judgements about what works, how quickly capability is improving, and what the technology means for their own work. A casual user encounters an unreliable conversational interface, while a specialist may be integrating increasingly capable systems into coding, research, analysis, or operational workflows. Both observations can be accurate at the same time, which makes public debate unusually vulnerable to confusion. That split is partly a matter of exposure. Adoption is growing quickly, but it is still uneven across populations, occupations, organisations, and use cases. A nationally representative US survey found that nearly 40 percent of people aged 18 to 64 had used generative AI by late 2024, while 23 percent of employed respondents had used it for work during the previous week and 9 percent used it every working day. Later tracking reported that 37,4 percent of employed respondents had adopted the technology for work by August 2025, alongside 54,6 percent of the wider working-age population using it at work or home. These figures describe adoption, not competence or impact. A person who asks a chatbot for a recipe, a student who requests an explanation, a marketer who drafts copy, and a software engineer who uses an agent to inspect a repository are counted within the same broad category. Their experiences are not comparable. The first may judge the system by fluency and occasional factual errors; the last may judge it by the number of useful changes it can make across a large codebase. Segmentation by task is therefore more informative than a single user percentage. Why the productivity experience diverges Workplace gains depend on the relationship between a model, a task, and the surrounding process. When the task is well specified, digitally accessible, repetitive, and easy to verify, AI can remove substantial friction. When success depends on tacit knowledge, ambiguous objectives, accountability, or long chains of dependent decisions, the same system may create more checking work than it removes. The relevant question is not whether a model is generally intelligent, but whether it can reliably complete a particular part of a workflow at an acceptable cost. Available evidence supports both modest and substantial accounts of impact. In late 2024, respondents to the Real-Time Population Survey reported time savings equivalent to 1,4 percent of total work hours, while users saved considerably more during the hours in which they actually used the technology. A Federal Reserve analysis estimated that the implied aggregate productivity effect could reach 1,1 percent, while noting that the gain was concentrated among users and particular occupations. By August 2025, another analysis estimated aggregate time savings at 1,7 percent of total worked hours and suggested a possible productivity increase of up to 1,3 percent since the arrival of ChatGPT. Those estimates should not be mistaken for settled measurements of long-term economic output. They rely partly on self-reported time savings, and saved time can be absorbed by additional work, higher quality standards, organisational delay, or new verification requirements. A worker may complete a draft more quickly but spend the difference reviewing errors. A company may gain capacity without reducing headcount. Productivity can rise at the task level while remaining difficult to observe in national statistics. The capability curve and the interface problem The most consequential source of divergence is the distance between publicly available interfaces and the strongest systems used by advanced practitioners. Consumer products often expose a general-purpose assistant designed to be safe, accessible, and responsive across many contexts. Specialist users may instead work with better models, larger context windows, tool access, custom data, evaluation harnesses, persistent memory, and multi-step agents. The resulting difference is not merely a matter of expertise. It is a difference in the system being evaluated. Technical progress has also become uneven across capabilities. The Stanford AI Index reported that performance on SWE-bench rose from 4,4 percent in 2023 to 71,7 percent in 2024, while noting that difficult benchmarks still expose substantial weaknesses. Its subsequent reporting described performance approaching 100 percent on SWE-bench Verified in 2025, although autonomous software engineering and computer-use tasks remained areas where systems could fall below human baselines. The UK AI Security Institute likewise reported rapid improvement in tested frontier capabilities, including a rise in success on apprentice-level cyber tasks from 9 percent in late 2023 to 50 percent in its later testing. Such benchmark movement can feel vertical to people whose work is close to the frontier, particularly when several improvements arrive together: better reasoning, stronger tool use, longer context, lower costs, and more reliable execution. Yet benchmark scores do not automatically translate into dependable autonomy. A system can solve a constrained test while failing in an unfamiliar environment, misunderstanding a requirement, or producing an answer that is difficult to audit. The apparent acceleration is therefore real in some dimensions, but its practical value remains conditional. Three realities operating together The public reality is shaped by visibility and disappointment. People encounter generated text, images, or answers in products that may be limited by access, poor prompting, weak integration, or cautious product design. Errors are memorable, especially when they concern basic facts. Because most people do not routinely compare models or construct evaluation pipelines, they may reasonably infer from these encounters that progress has been incremental or cosmetic. The professional middle experiences a more modest uplift. Many workers use AI for brainstorming, summarisation, translation, drafting, meeting notes, or routine analysis. These applications can save minutes without changing the structure of a job. They may improve convenience rather than create a dramatic change in output. Organisational policies, data restrictions, procurement processes, and uncertainty about responsibility further limit the effects. Adoption can therefore be widespread while transformation remains shallow. A smaller frontier-facing group experiences a different phenomenon. These users repeatedly test systems against difficult tasks, connect them to tools, and redesign processes around their strengths and limitations. Their learning compounds because each successful experiment reveals another use case. They may move from asking for an answer to assigning a bounded objective, providing context, checking intermediate results, and letting the system execute part of the workflow. The gain comes from the combination of model capability and workflow redesign, not from the chat interface alone. Objections and limits There are good reasons to resist dramatic interpretations. Capability demonstrations can overrepresent favourable tasks, omit failed attempts, and blur the difference between assistance and independent responsibility. Frontier systems remain prone to hallucination, brittle reasoning, security failures, and inconsistent behaviour. Access is also unequal: expensive models, specialised tools, high-quality data, and technical expertise are not distributed evenly. A small group may therefore experience a genuine transformation without that experience representing the median worker or consumer. There is an equally serious risk in treating ordinary experience as a reliable forecast of the frontier. Current interfaces are not fixed descriptions of future use. Costs can fall, models can become more dependable, and tools can make complex capabilities easier to deploy. The gap between expert and general users may narrow, but it could also widen if the most valuable advances require engineering skill, proprietary data, or organisational authority. Policymakers and business leaders therefore need measures that distinguish access, frequency, task completion, quality, supervision, and economic value rather than relying on a single adoption headline. The strategic implication is that AI change will not arrive as one uniform wave. It will appear first where tasks are measurable, digital, and easy to decompose, then spread through organisations that can redesign roles and controls around the technology. Public scepticism, moderate workplace gains, and intense frontier optimism can coexist because they describe different layers of the same transition. The important question is where a system sits in a workflow, what evidence supports its reliability, and who bears the cost when its confidence exceeds its competence.
|
| |
!["This is the weirdness of the moment. The general public has mostly not interacted with [AI]. When they have, it looks like a derpy chatbot. The majority of professionals still see only a modest uplift. And a small sliver of professionals are experiencing the vertigo of the curve going vertical. And it is all happening at the same time." - Quote: Andrej Karpathy - AI guru, Anthropic](https://globaladvisors.biz/wp-content/uploads/2026/10/20261012_06h46_GlobalAdvisors_Marketing_Quote_AndrejKarpathy_GAQ.png)
| |
Term: AI primitive - Artificial intelligence"In AI development, primitives are the fundamental, low-level building blocks - such as prompt routing, vector memory, tool calling, and evaluation steps - used to construct modular and reliable AI workflows. Rather than relying on rigid, monolithic frameworks that obscure the underlying logic, developers treat these modular components as atomic units of capability that can be custom-stitched together." - AI primitive - Artificial intelligence Reliable AI applications are assembled from decisions that can be inspected, tested, replaced, and governed independently. A model may generate language, but production behaviour depends on the surrounding mechanisms that select context, invoke services, preserve state, constrain actions, and check results. Treating these mechanisms as modular units changes development from configuring one opaque application into designing a system whose capabilities and failure modes can be examined piece by piece. An AI primitive is therefore a small, reusable unit of capability or control in an artificial intelligence workflow. It need not be a single software function, and it is not necessarily tied to one vendor or model. A retrieval operation, a prompt selector, a structured-output validator, a tool interface, a memory store, a human approval gate, and an evaluation routine can each serve as a primitive when it has a clear purpose and boundary. The useful test is practical: can the component be understood, measured, substituted, and composed with others without rewriting the whole application? This approach distinguishes a capability from a framework. A framework supplies conventions, abstractions, integrations, and often a ready-made execution model. It can accelerate prototyping, but it may also conceal control flow and make debugging dependent on framework-specific behaviour. Primitives expose more of the underlying logic. Developers can use a simple sequence of model calls and ordinary program code when that is sufficient, then add routing, retrieval, tools, or longer-running loops only where the task requires them. Research and engineering guidance similarly distinguishes predictable workflows, in which code determines the path, from agents, in which a model dynamically selects actions. How the building blocks work together Prompt routing is a decision layer that directs an input to an appropriate instruction set, model, tool chain, or level of scrutiny. A classifier might send a billing query to a narrow workflow and a complex research request to a more capable one. Routing can reduce cost and latency, but it introduces its own risks: ambiguous requests may be assigned to the wrong path, and a routing model can become a hidden source of bias or inconsistency. Its quality must therefore be assessed separately from the quality of the downstream response. Vector memory is another common primitive. Documents, records, or prior interactions are converted into numerical representations and stored so that semantically related material can be retrieved later. Retrieval can improve factual grounding without retraining the main model, yet similarity is not the same as relevance. A system may retrieve outdated, duplicated, sensitive, or misleading material. Effective designs combine semantic search with metadata filters, access controls, freshness rules, and explicit handling for cases in which no trustworthy source is found. Tool calling connects a model to external operations such as databases, calculators, search services, code execution, or transactional systems. The interface should specify the permitted inputs, outputs, permissions, error states, and side effects. Documentation is not cosmetic: the model uses the available description to decide whether and how to invoke a tool, so vague names and broad schemas can produce unreliable actions. Anthropic recommends testing tool use systematically and measuring not only task success but also tool errors, runtime, call volume, and token consumption. Memory, tools, and retrieval also create a boundary between language generation and real-world consequence. A generated answer can be corrected in conversation; an unauthorised database update or financial transaction may be difficult to reverse. Strong systems separate read operations from write operations, limit credentials, validate arguments in deterministic code, and place approval gates around consequential actions. Sandboxed testing and explicit guardrails are especially important when an agent can alter files, call external services, or continue through multiple steps. Specification, composition, and evaluation Composition is valuable because different tasks need different arrangements. A sequential workflow may retrieve evidence, draft an answer, verify citations, and format the result. Parallel branches may ask several specialised components to inspect the same input before an aggregator reconciles them. An evaluator-optimiser pattern can generate an output, score it against defined criteria, and revise it. These patterns are not automatically superior to a single model call. Added steps increase latency, cost, state-management complexity, and the number of places where errors can accumulate. The appropriate architecture is the simplest one that meets the required quality and control level. Evaluation is itself a primitive rather than a final ceremonial check. A useful evaluation defines realistic tasks, observable success criteria, representative edge cases, and a repeatable grading method. Code-based tests are suitable for exact formats and executable outcomes; model-based graders can assess open-ended quality; human review remains important where context, fairness, safety, or professional judgement matter. Anthropic describes agent evaluation as requiring an environment in which the system can use its tools and produce an outcome that can be checked, rather than merely generating an attractive response. Formally, a workflow can be viewed as a composition of functions, where each component transforms a state into a new state: . Here is the system state at step , is the relevant input or observation, and is a primitive such as retrieval, routing, generation, validation, or tool execution. If the final outcome is scored by an evaluation function , where is the produced result and is the target outcome, improvement requires measuring how changes to individual affect quality, cost, latency, and risk. The notation does not make the system reliable by itself; it clarifies where reliability can be tested. Competing design philosophies One school favours high-level platforms and opinionated frameworks. Their advantage is speed: standard connectors, tracing, memory abstractions, retries, and agent loops can be assembled quickly, allowing teams to validate a use case before building infrastructure. Another school favours minimal orchestration and explicit code. Its priorities are transparency, portability, predictable control flow, and freedom from abstractions that may become difficult to replace. A third position treats the choice as conditional. High-level components are useful when they reduce undifferentiated engineering work, but core decisions should remain visible enough to audit and test. The main tension is not frameworks versus no frameworks. It is convenience versus control. A reusable primitive can reduce duplication, yet excessive fragmentation can create an architecture that is hard to understand and expensive to observe. Stable interfaces are essential: each component should state its contract, assumptions, failure behaviour, security requirements, and performance expectations. Versioning matters as well, because changes to a prompt, embedding model, retrieval index, tool schema, or evaluator can alter downstream behaviour even when application code remains unchanged. Governance must follow the same modular logic. NIST's AI Risk Management Framework organises practical risk work around governing, mapping, measuring, and managing risks, and recommends testing before deployment and during operation. Its generative AI profile adds emphasis on ongoing monitoring, documented evaluation, incident response, and review of risk controls. These recommendations reinforce a central implication of primitive-based design: quality, safety, provenance, and access control should be observable at the points where decisions and actions occur, not inferred only from the final text. The concept remains important because model capability alone does not determine system performance. Organisations need to replace models, update knowledge, introduce new tools, control costs, and adapt to changing regulations without rebuilding every application. Modular primitives make those changes technically possible and analytically legible. They also expose a less comfortable truth: composability does not remove risk. It distributes risk across interfaces, state transitions, permissions, data sources, and evaluation gaps. The strongest AI systems therefore combine small, explicit building blocks with disciplined testing, constrained authority, production monitoring, and human oversight where consequences warrant it.
|
| |
| |
Riyadh airport closure extended after Houthi attacksThe Global Advisors Daily Business News briefing for 13 October 2026, hosted by Sam. Ten headlines shaping markets, technology and corporate strategy, with context on the stories that matter. Read the full newsletter: https://with.ga/pgcem In this edition: - Hyperscalers Accelerate Proprietary AI Chip Deployments to Curtail Nvidia Dependency Amid Capital Bottlenecks Follow the daily podcast on Spotify: https://with.ga/spotnews Subscribe to the daily podcast on YouTube: https://with.ga/ytnews Get free daily updates on WhatsApp: https://with.ga/wa Read the full briefing and explore our strategy insights: https://globaladvisors.biz Follow on Spotify: https://with.ga/spotnews |
| |
| |
Global Advisors News Brief - October 13 2026Read the full brief at the link Headlines for the last 24hrs
Time window: 2026-10-12T03:30:33.514Z to 2026-10-13T03:30:33.514Z |
| |
| |
Quote: Satya Nadella - Microsoft CEO"The most trustworthy Super Intelligence system will not be the one with the model we trust most. It will be the one that enables us to trust the model the least." - Satya Nadella - Microsoft CEO The decisive question for advanced artificial intelligence is not whether a model appears persuasive, capable, or aligned in ordinary use. It is whether the surrounding system can contain the consequences of a model that is wrong, manipulated, unexpectedly competent, or operating beyond the assumptions of its designers. That distinction shifts trust from a feeling about an intelligence to a property of an architecture. The supplied statement points towards a security principle: powerful models should be treated as potentially unreliable components, while permissions, verification, monitoring, and human accountability remain outside them . That principle matters because capability and dependability are not the same thing. A system can generate excellent answers while still failing unpredictably at the boundary of its training data, inventing evidence, misunderstanding a goal, or following instructions embedded in hostile content. As models gain access to software tools, private records, financial systems, laboratories, and industrial controls, a single plausible error can become an operational event. The risk is therefore not limited to incorrect text. It includes unauthorised actions, concealed escalation, privacy loss, fraud, and failures that are difficult to reconstruct after the fact. The practical response is to separate cognition from authority. A model may propose an action, but a different control layer should determine whether that action is permitted, within scope, reversible, and adequately supported. Access rights should be narrow; sensitive operations should require confirmation; tool calls should be logged; outputs should be tested against independent checks; and high-impact decisions should retain a responsible human or institutional owner. In a simplified risk model, expected loss can be represented as , where is the probability of failure mode and is its consequence. Reducing reliance on the model can lower even when its underlying error probability remains difficult to estimate. From model confidence to system control Conventional software engineering already recognises that no single component should be trusted with every responsibility. Authentication, authorisation, input validation, transaction limits, audit trails, and recovery procedures exist because code can fail and because legitimate credentials can be misused. Applying the same logic to advanced AI means resisting the temptation to make a model the final judge of its own reliability. A model can explain its reasoning, but the explanation is not automatically proof. It can claim that a tool call is safe, but the policy engine should make that determination. It can assess another model, but independent evaluation remains necessary. NIST's AI Risk Management Framework describes trustworthy AI through several characteristics, including validity and reliability, safety, security and resilience, accountability and transparency, explainability and interpretability, privacy enhancement, and fairness with harmful bias managed . Its operating structure is organised around governing, mapping, measuring, and managing risk across the AI lifecycle . This supports the architectural reading of the statement: trust is not a single score attached to a model. It is the result of controls that continue to function when the model is uncertain, adversarially prompted, updated, connected to new tools, or deployed in a different social context. The framework also exposes a difficult trade-off. A system may be more interpretable but less capable, more secure but less convenient, or more heavily monitored but slower to operate. NIST cautions that trustworthy characteristics cannot simply be evaluated in isolation and that different use cases require different balances . A low-risk drafting assistant does not need the same controls as an automated system influencing credit, medical treatment, employment, public safety, or critical infrastructure. Treating every application as equivalent either wastes resources or leaves consequential deployments under-protected. Why superintelligence changes the argument The word superintelligence raises the stakes because it implies capabilities that could exceed human performance across multiple domains. Whether that label is used precisely or rhetorically, the governance problem is recognisable: oversight becomes harder when a system can plan over long horizons, exploit complex environments, write and execute code, persuade users, or identify weaknesses in the controls intended to constrain it. A more capable system may be better at following safety procedures, but it may also be better at finding loopholes, concealing intermediate steps, and optimising for a proxy rather than the intended objective. This creates an asymmetry between capability and oversight. Human operators may approve a system because its demonstrations are impressive, yet demonstrations sample only a small fraction of possible situations. Evaluation must therefore include adversarial testing, realistic deployment conditions, continuous monitoring, and checks for changes after updates. NIST's generative AI guidance recommends assessing risk-relevant capabilities and the robustness of safeguards before deployment and on an ongoing basis . The requirement is especially important when models are combined into agents, because the risk of a sequence of individually acceptable actions can exceed the risk of any single step. External scrutiny is also essential. Internal testing can be constrained by commercial incentives, limited access to training information, or assumptions shared across the development team. Independent red-teaming, incident reporting, model evaluations, and regulator access can reveal failure modes that a developer's own benchmarks miss. These measures do not eliminate uncertainty, but they make it harder for confidence to rest solely on a vendor's claims. The result is a shift from asking whether a model is trustworthy to asking who can challenge it, which evidence supports its deployment, and what happens when the evidence changes. The objections and the limits There are reasonable objections to placing too little trust in models. Excessive suspicion can make useful systems cumbersome, reduce productivity, and encourage users to bypass controls. Human beings are not automatically safer alternatives: people are inconsistent, vulnerable to persuasion, and capable of approving mistakes at scale. In some settings, a well-tested model may be more reliable than an overstretched operator. A blanket rule that every output requires human approval can therefore create an appearance of safety without meaningful review. The answer is not distrust as a permanent refusal to use AI. It is calibrated reliance. Controls should correspond to the severity, reversibility, and detectability of failure. Low-impact tasks can use automated checks and sampling, while irreversible or rights-affecting actions require stronger authorisation, provenance, contestability, and appeal. Organisations should also define stop conditions in advance: when uncertainty rises, evidence conflicts, monitoring detects abnormal behaviour, or the operating environment changes, the system should reduce its permissions or stop rather than improvise. Another limitation is that architecture cannot solve every governance problem. A technically well-controlled model can still be deployed for an unjust purpose, trained on unlawfully obtained data, or used within an organisation that obscures responsibility. Trust also depends on institutions, law, procurement, professional standards, and public accountability. NIST presents its framework as voluntary and adaptable rather than as a substitute for regulation . The broader lesson is that technical safeguards need enforceable duties and clear ownership if they are to survive commercial pressure. Why the idea matters for Microsoft and the market For a company operating across cloud infrastructure, productivity software, developer tools, and enterprise security, the architectural approach has direct strategic significance. The competitive advantage may move away from a marginally stronger model and towards a platform that can offer granular permissions, reliable auditability, secure data boundaries, policy enforcement, and evidence that safeguards operate in practice. Enterprises will not evaluate advanced AI only by asking which system writes the best answer. They will ask whether it can be governed across thousands of users, integrated with existing controls, investigated after an incident, and restricted without disabling the entire service. That changes the market definition of trust. Trust is no longer equivalent to confidence in a brand, a benchmark score, or a model's fluent explanation. It becomes a measurable institutional capability: the ability to limit authority, detect failure, preserve evidence, recover from harm, and assign responsibility. The least-trusted component can therefore sit inside the most trustworthy system, provided the system is designed so that its errors do not automatically become decisions. For advanced AI, that is not an argument against capability. It is an argument for building capability inside an architecture that never confuses intelligence with permission.
|
| |
| |
Term: Bring Your Own Agent (BYOA) - Artificial intelligence"Bring Your Own Agent (BYOA) is a concept where users, developers, or employees supply their own custom or preferred autonomous AI agents (such as Claude Code, ChatGPT Codex and Dots, Muse, GrokBot or custom enterprise bots) to work within an external platform, development environment, or organisation's data infrastructure, rather than being forced to use a single vendor's built-in tool." - Bring Your Own Agent (BYOA) - Artificial intelligence The practical issue is control over agency. When software can interpret goals, select tools, retrieve information and execute actions, the choice of agent becomes an architectural decision rather than a matter of personal preference. A BYOA arrangement permits a developer, employee or external partner to bring an agent into an existing platform or organisational environment, provided that the host can authenticate it, constrain its permissions, observe its behaviour and remove it when necessary. The result is a shift from a single-assistant model towards a governed ecosystem of agents with different capabilities, costs, data policies and operational assumptions. In substance, BYOA separates the agent from the environment in which work occurs. The agent may be a general conversational system, a coding specialist, a research assistant, a workflow bot or a custom enterprise service. The external environment supplies the data, tools, APIs, repositories and business processes that give the agent practical power. This distinction matters because an agent that merely drafts text has a different risk profile from one that can alter source code, approve payments, send messages or query confidential records. Microsoft describes enterprise agents as software that can access data, make decisions and act across business systems under delegated authority. Why organisations want agent choice Allowing users to bring preferred agents can increase experimentation and reduce dependence on a single vendor. Teams may select a coding agent for repository work, a specialist model for document extraction or a privately hosted system for sensitive information. Developers can test new tools without waiting for a central procurement cycle, while organisations can preserve existing workflows instead of forcing every task through one proprietary assistant. This flexibility can also improve resilience: if one model becomes unavailable, too expensive or unsuitable for a particular task, another may be substituted at the integration layer. The advantage is not unlimited freedom. A useful BYOA design defines the boundary between choice and control. The host platform should treat every agent as an identifiable software principal, record its owner and purpose, and specify which data and tools it may access. A registry, approval process and lifecycle policy are therefore more important than a simple catalogue of available bots. Microsoft reports that enterprise control planes are being designed to inventory agents built on internal platforms, open-source frameworks and third-party systems, with visibility into deployment, access, behaviour and cost. Identity, permissions and the action boundary The hardest governance question is not which model generated an answer, but which authority enabled an action. An agent should not inherit a person's full access merely because that person installed it. The stronger pattern is a distinct machine identity, narrowly scoped credentials and permissions tied to a specific task. This prevents a coding assistant, for example, from receiving unrestricted access to production infrastructure when it only needs a development repository. OpenID contributors responding to NIST identified credential sharing between humans and agents as an urgent risk, particularly where passwords, API keys, OAuth tokens or session cookies are passed directly to agents. Permission design must also account for delegation. An agent may call a tool, which may call another service, or it may delegate a task to a second agent. Each step should preserve identity, authorisation context and an auditable record of the decision. Otherwise, a compromised or poorly configured component can become a confused deputy that exercises another system's authority without clear accountability. Sensitive actions should use approval gates, transaction limits, sandboxing and rollback mechanisms. The principle is simple: the more irreversible the action, the stronger the confirmation and monitoring requirements. Interoperability without uncontrolled complexity BYOA depends on interfaces that allow an external agent to communicate with tools and services without requiring a complete rewrite of the host environment. Protocols for tool access and agent-to-agent communication can reduce vendor lock-in, but interoperability does not automatically create safety. Shared interfaces also create shared attack surfaces. Microsoft identifies agent-to-agent protocols as a way for systems from different vendors, frameworks and clouds to communicate, delegate and coordinate, while pairing that openness with identity, policy, audit and access-boundary controls. Standardisation remains contested. A common protocol may improve portability, yet its implementation can differ across vendors, and a protocol does not establish whether an agent is trustworthy, whether its supplied context is reliable or whether its requested action is appropriate. Model Context Protocol, for example, can connect agents to tools, data sources and services, but the surrounding organisation still has to vet servers, restrict external interactions and validate communications. The architectural lesson is that interoperability should be treated as a controlled capability, not as an exemption from security review. Prompt injection and supply-chain risk Traditional software normally follows explicit code paths, whereas agents interpret natural-language context assembled from documents, websites, email, tool responses and other agents. This creates a distinctive prompt-injection problem: hostile instructions can be embedded in material the agent is asked to process and may redirect its behaviour. The risk becomes more serious when the agent can act on the outside world. Guidance summarised by the Cloud Security Alliance identifies prompt injection, tool misuse, unauthorised delegation and cascading failures as agent-specific governance concerns. BYOA expands the supply chain because an organisation may not control the model provider, orchestration framework, plugins, memory store, tool server or delegated agents. Due diligence should therefore cover provenance, update practices, data retention, logging, model substitution and incident response. Runtime controls are essential because pre-deployment testing cannot anticipate every document, API response or instruction that an agent will encounter. Useful controls include input separation, allow-listed tools, network restrictions, anomaly detection, human review for high-impact actions and complete records of the context, permissions and approvals involved. Competing models of governance One school of thought favours a central platform: the organisation supplies approved agents, common identity controls, standard evaluations and a unified monitoring layer. This approach simplifies support, compliance and incident response, but can reproduce the very vendor dependence that BYOA seeks to avoid. A second model favours federated choice, in which teams select agents within common technical and policy boundaries. It encourages innovation and local expertise, but creates variation in data handling, evaluation quality and operational maturity. A third model treats agents as an internal marketplace: users can choose from registered providers, while the platform enforces policy at the point of connection and action. These models also differ on where trust should reside. Model-centred governance concentrates on accuracy, refusal behaviour and testing. Identity-centred governance asks who owns the agent, what it can access and how its credentials are managed. Systems governance adds the surrounding tools, data, workflows and human approvals. The evidence from current enterprise guidance supports the broader view: agents must be observable, governed and secure because their delegated authority can affect multiple systems at once. No single model evaluation can answer those operational questions. Why BYOA still matters BYOA matters because autonomous software is becoming a layer between people and organisational systems. Employees will continue to discover useful agents outside formal procurement, and developers will continue to combine models, tools and workflows in ways that central IT cannot fully predict. Prohibiting that behaviour may reduce visible risk while encouraging shadow deployments that are harder to inventory. A controlled BYOA policy offers a more realistic alternative: allow experimentation, but require registration, distinct identity, least-privilege access, approved integrations, data boundaries, monitoring, review and rapid revocation. The decisive test is whether an organisation can explain what an imported agent is allowed to do, what information it received, which tools it invoked, which other agents it contacted and who approved consequential actions. If those answers are unavailable, the organisation has adopted an opaque dependency rather than achieved meaningful choice. BYOA is therefore best understood not as unrestricted personal software, but as a governance pattern for making agent diversity compatible with accountability, interoperability and security.
|
| |
| |
Your daily business briefing - now a Spotify podcastStay informed on the business stories that matter, wherever your day takes you. The Global Advisors Daily Business News podcast brings you the featured stories from our daily newsletter, with supporting context and analysis of what they could mean for markets, businesses and leadership. Hosted by Sam, each episode goes beyond the headlines to explore the developments shaping executive decisions - from technology and artificial intelligence to economic policy, capital markets and corporate strategy. Read the newsletter for the headlines and source links. Listen to the podcast for a deeper briefing. Subscribe now on Spotify at https://with.ga/spotnews |
| |
| |
Your daily business briefing - now a YouTube podcastStay informed on the business stories that matter, wherever your day takes you. The Global Advisors Daily Business News podcast brings you the featured stories from our daily newsletter, with supporting context and analysis of what they could mean for markets, businesses and leadership. Hosted by Sam, each episode goes beyond the headlines to explore the developments shaping executive decisions - from technology and artificial intelligence to economic policy, capital markets and corporate strategy. Read the newsletter for the headlines and source links. Listen to the podcast for a deeper briefing. Subscribe now on YouTube at https://with.ga/ytnews |
| |
| |
Amazon reported in talks to acquire AI startup DecartThe Global Advisors Daily Business News briefing for 12 October 2026, hosted by Sam. Ten headlines shaping markets, technology and corporate strategy, with context on the stories that matter. Read the full newsletter: https://with.ga/47x95 In this edition: - Persistent Surge in Sovereign Bond Yields Strains Corporate Balance Sheets and Threatens Equity Valuations Follow the daily podcast on Spotify: https://with.ga/spotnews Subscribe to the daily podcast on YouTube: https://with.ga/ytnews Get free daily updates on WhatsApp: https://with.ga/wa Read the full briefing and explore our strategy insights: https://globaladvisors.biz Follow on Spotify: https://with.ga/spotnews |
| |
| |
|
| |
| |