Category: Uncategorized

The decision

Do you build your next internal service or product backend as a modular monolith (single deployable, strong internal boundaries), or jump straight to microservices (many independently deployed services)?

This isn’t a style preference. It’s a bet on where your complexity will live: inside the codebase (monolith) or in the system (microservices). Most teams underestimate the cost of the latter.

What actually matters

1) Team topology and deploy independence

Microservices pay off when you have multiple teams that truly need independent deploy cadence and can own services end-to-end (on-call, data, SLOs). If your teams are still coupled on product decisions, schema changes, or shared roadmaps, microservices won’t create independence—they’ll just make coupling harder to see.

2) Operational maturity (and appetite)

Microservices require competency in:

• Service discovery/routing, timeouts/retries, backpressure
• Centralized logging/metrics/tracing
• Incident response across service boundaries
• Versioning and backwards compatibility
• Secure service-to-service authN/authZ

If you don’t already run this kind of platform (or are willing to build one), microservices will tax your delivery speed for a long time.

3) Data boundaries and transaction needs

The “real” breakpoint is usually data:

• If you need strong consistency across domains with frequent cross-entity transactions, microservices push you into sagas/outbox/eventing patterns that are harder to reason about.
• If you have naturally separable domains (billing vs search vs notifications) with clear ownership and looser consistency needs, microservices get easier.

4) Change velocity vs safety

A modular monolith optimizes for fast refactors and global correctness (rename a type, update callers, ship once). Microservices optimize for local autonomy and failure isolation, but make cross-cutting changes slower and riskier.

Quick verdict

Default for most teams: start with a modular monolith. Get clean module boundaries, a stable domain model, and a boring deploy pipeline. Split into microservices only when you can name the specific boundaries and the organizational reasons that require independent deploy and scaling.

Microservices are a scaling strategy for teams and operations, not just traffic.

Choose modular monolith if… / Choose microservices if…

Choose a modular monolith if…

• You’re one team or a few teams shipping a single product with shared priorities.
• You expect frequent cross-domain refactors (the product is still taking shape).
• You need simpler correctness (transactions, invariants, migrations) and want to keep those easy.
• You don’t have (or don’t want to build) a full service platform with tracing, standardized libraries, golden paths, etc.
• Your main bottleneck is feature throughput, not independent scaling or isolation.

Decision rule: If you can’t point to at least two domains that almost never need coordinated releases, you probably don’t want microservices yet.

Choose microservices if…

• You have multiple durable teams that must ship independently and own production outcomes.
• You can define hard domain boundaries with minimal shared tables and minimal shared release coordination.
• You need failure isolation (one subsystem going down must not take down the rest) beyond what a monolith + bulkheads can reasonably provide.
• You have real needs for independent scaling or specialized runtime characteristics (e.g., one component is latency-critical, another is batch-heavy).
• You’re prepared to standardize on:
• API contracts and compatibility policy
• Observability and incident processes
• Platform tooling (CI/CD templates, service templates, runtime baselines)

Decision rule: If your org can’t support “you build it, you run it” ownership, microservices will devolve into distributed blame.

Gotchas and hidden costs

Microservices: the “distributed tax”

• Network becomes your new control flow. Partial failure is normal; timeouts and retries need discipline or you’ll create cascading outages.
• Debugging gets slower. Without excellent tracing and consistent correlation IDs, you’ll spend hours reconstructing a single request path.
• Data consistency pain. Cross-service invariants become eventual. You’ll need idempotency, dedupe, and compensations everywhere.
• Contract drift. Without strict versioning and compatibility tests, changes break downstream consumers in production.
• Security surface area explodes. Service-to-service auth, secrets distribution, least privilege, and ingress/egress policies stop being “later.”

Monolith: the “big ball of mud” risk (but optional)

The monolith failure mode is usually self-inflicted:

• No module boundaries, no ownership, no dependency rules
• “Just one more shared utility”
• Global runtime config and feature flags that become untestable

A modular monolith avoids this by treating modules like internal services:

• Enforce boundaries (package visibility, dependency rules, linting)
• Define stable internal APIs
• Keep domain data ownership explicit even if it’s in one database

Cost and lock-in (both sides)

• Microservices can lock you into a platform (service mesh, gateways, internal frameworks) and a process (compatibility gates).
• Monoliths can lock you into a single release train and shared runtime constraints (language/runtime upgrades are all-at-once).

How to switch later

If you start with a modular monolith (recommended path)

Design for extraction without premature distribution:

• Hard modules, soft runtime: Keep module APIs explicit and avoid reaching into another module’s internals.
• Own your tables by module. Even in one DB, make it obvious who owns which schema.
• Prefer asynchronous boundaries where it’s natural. Don’t force eventing everywhere, but where domains are already async (notifications, analytics), make it real.
• Avoid shared “god” libraries that embed business rules. Shared libraries should be boring (logging, auth client), not domain logic.

When you extract:

• Lift a module behind a network boundary (same API), keep behavior identical.
• Keep rollback simple: the extracted service can temporarily call back into the monolith (carefully) or run behind a feature flag.

If you start with microservices (hard mode)

If you’re already distributed:

• Invest early in golden paths (service template, common middleware, standard telemetry).
• Add contract testing and compatibility CI gates.
• Reduce shared DB/“integration by table.” That’s a monolith with worse failure modes.

Rollback plan: treat every cross-service change like a two-phase deploy (backwards-compatible producer, then consumer, then cleanup). If you can’t do that reliably, you’ll ship fear.

My default

Build a modular monolith first, with strict module boundaries and clear data ownership. You’ll ship faster, refactor more safely, and learn your domain boundaries while the product is still moving.

Graduate to microservices only when:

• the org structure demands true independent deploys,
• the domain boundaries are stable and enforceable,
• and you can afford the operational platform that makes microservices survivable.

Most teams don’t fail because they chose the “wrong architecture.” They fail because they chose an architecture whose hidden costs didn’t match their team’s maturity and incentives.

The decision

Do you standardize your org’s “internal API” on gRPC or REST/JSON?

This isn’t a bikeshed. It determines how fast teams can ship cross-service changes, how observable and debuggable your system is under stress, and whether your platform becomes a force multiplier or a drag.

What actually matters

The gRPC vs REST fight is rarely about raw performance. The real differentiators are:

• Contract discipline and change management

• gRPC (with Protobuf) strongly encourages explicit schemas, backward-compatible evolution, and generated clients.

• REST often devolves into “whatever JSON the server returns,” unless you enforce schema + versioning rigorously.

• Client ecosystem and reach

• REST/JSON is the lowest common denominator: browsers, curl, vendors, third parties, and humans.

• gRPC is excellent service-to-service, but not “universal” at the edges without gateways/transcoding.

• Operational reality (debugging, tooling, on-call)

• REST is easy to inspect and replay. gRPC is inspectable too, but it takes more deliberate tooling and habits.

• If your on-call culture depends on “just curl it,” that’s a real cost to give up.

• Streaming and long-lived interactions

• If you need streaming (server, client, or bidirectional) as a first-class concept, gRPC is the more natural fit.

• You can do streaming with HTTP-based patterns, but it’s less uniform across clients and infra.

• Cross-language correctness

• With many languages and many teams, generated clients + strict schemas reduce accidental breakage.

• REST can be fine here too, but you must invest in schema (e.g., OpenAPI) and compatibility checks.

Quick verdict

Default for most teams:

• Internal service-to-service: gRPC (Protobuf, generated clients, schema-first)
• External/public APIs and browser-facing: REST/JSON (with OpenAPI, consistent error model, and explicit versioning)

If you’re trying to pick one for everything: pick REST/JSON unless you’re sure your primary pain is internal API change management and cross-language correctness at scale.

Choose gRPC if… / Choose REST if…

Choose gRPC if…

• You’re mostly solving internal platform problems. Many services, many owners, frequent interface changes.
• You need streaming or “real RPC” semantics (bidirectional streaming, long-lived calls, structured timeouts/cancellation).
• You have polyglot services and want generated clients to be the default path (fewer hand-written SDKs).
• You want schema discipline by construction. Protobuf nudges teams toward compatibility rules and smaller payloads.
• You control the clients (service-to-service, trusted first-party apps) and don’t need universal accessibility.

Choose REST/JSON if…

• Humans and third parties will use it. You want every tool to work out of the box.
• You’re at the edge. Browsers, partners, vendor integrations, API marketplaces, simple auth flows, and caching/CDN patterns.
• Your org isn’t ready to enforce contract rigor. REST can be forgiving early, while you mature governance.
• You rely on ubiquitous infrastructure behaviors (HTTP caching semantics, simple proxies, WAF rules tuned for HTTP/JSON).
• Debuggability and incident response are optimized around “inspect the request/response fast.”

Gotchas and hidden costs

gRPC gotchas

• Operational “opacity” unless you invest in tooling. You’ll want:
• consistent reflection / server metadata policy,
• standardized client retries/timeouts,
• structured logging with request IDs and clear method names,
• easy ways to replay calls in lower environments.
• Gateway complexity at the edges. If you later need browser/partner access, you’ll end up with:
• gRPC ↔ HTTP/JSON translation,
• duplicated auth/rate-limiting policy layers,
• “two faces” of the same API that can drift if you’re sloppy.
• Compatibility discipline is required, not optional. Protobuf makes it possible to evolve safely, but teams can still break you with bad field changes or poor versioning hygiene. You need CI checks and review standards.

REST/JSON gotchas

• Schema drift becomes technical debt fast. If you don’t enforce OpenAPI (or equivalent) and compatibility rules, clients will hardcode quirks and you’ll be stuck supporting them.
• Client libraries become a tax. Without generated clients as the norm, every language/team may reinvent:
• auth signing,
• pagination conventions,
• retries/timeouts,
• error handling.
• Inconsistent semantics across teams. REST only “works” org-wide if you standardize:
• resource naming,
• error format,
• idempotency rules,
• pagination/filtering patterns,
• versioning strategy.

Shared failure modes (either choice)

• Retries without idempotency will burn you. Decide early which operations are safe to retry and encode that in your guidelines.
• Time-outs and cancellation need to be standardized. Most production incidents aren’t “slow,” they’re “slow plus retry storms.”
• AuthN/AuthZ policy sprawl is the real lock-in. Centralize it (service mesh, gateway, or shared libs) or you’ll regret it.

How to switch later

You don’t want a religious war; you want an escape hatch.

• Start by standardizing the contract, not the transport.

• If you pick REST: require OpenAPI and compatibility checks in CI.

• If you pick gRPC: require Protobuf linting, breaking-change detection, and explicit deprecation policies.

• Avoid leaking transport-specific details into business logic.

• Keep “HTTP-isms” (status code branching, header magic) out of core domain code.

• Keep “RPC-isms” (method naming tied to internals) from becoming your external contract.

• If you start with gRPC and later need REST at the edge:

• Plan for a gateway early, but don’t expose raw internal methods externally.

• Treat external APIs as a product: curated resources, stable semantics, long deprecation windows.

• If you start with REST and later move internal traffic to gRPC:

• Identify “high-churn, high-coupling” internal APIs first (the ones that break clients).

• Migrate service-to-service calls behind a thin client abstraction so callers don’t care.

• Keep REST for public/partner even if internals go gRPC—mixing is normal.

My default

Default: gRPC for internal service-to-service, REST/JSON for external.

If you force me to pick one across the board for a typical mid-sized team without heavy platform investment: REST/JSON with strict OpenAPI + compatibility enforcement. It’s easier to operate, easier to debug, and easier to adopt broadly. But if your biggest pain is cross-team API breakage and you’re already living in a microservices world, gRPC is the better internal contract machine—provided you commit to the tooling and governance that make it pay off.

The iPhone is “open” in Europe now. The market is still waiting.

Apple’s EU-only changes for the Digital Markets Act (DMA) were supposed to kick off a new era: alternative app marketplaces, more payment options, and a real way around the App Store’s single-lane distribution. And technically, that world exists today—Apple has added support for alternative marketplaces and “Web Distribution” (direct downloads) for apps in the EU.

But the more interesting story in early 2026 is that availability isn’t the same as viability. A headline example: Setapp Mobile—one of the more credible early alternative marketplaces—has announced it will shut down on February 16, 2026, explicitly blaming Apple’s complex and evolving terms.

So the debate has shifted from “Can Apple be forced to open iOS?” to “What does ‘open’ even mean if the economics and mechanics make competitors give up?”

What’s changing—and why it matters

Under the DMA, Apple had to introduce new distribution options in the EU: third-party app marketplaces and direct-from-website installation, along with related APIs, notarization, and authorization flows.

For engineers, IT, and product teams, this matters for three practical reasons:

• Procurement and deployment: If iOS distribution can diversify, enterprise and vertical software could move faster (less App Review friction, more tailored licensing, private catalogs).
• Payments and margins: Developers want optional payment rails—not necessarily to “avoid Apple,” but to run pricing experiments and bundle subscriptions across platforms.
• Security posture and trust: Any expansion of distribution paths changes threat models for end users and for organizations that manage iOS fleets.

In other words: DMA compliance isn’t just a policy fight. It’s a software supply chain change.

The real argument: four competing views of “openness”

There are (at least) four coherent positions here, and most people in the debate rotate between them depending on whether they’re speaking as a user, developer, regulator, or platform operator.

1) Regulators: “Choice requires more than a checkbox”

This view says Apple’s compliance can’t be evaluated purely on whether the APIs exist. If the process is so complex—or the fees so punishing—that only a token competitor survives, then users don’t get meaningful choice.

The Setapp Mobile shutdown is fuel for this argument: if a reputable subscription app brand can’t make the numbers work, what’s left besides niche stores and gray-market distribution?

2) Apple: “More distribution paths = more risk; guardrails are the point”

Apple’s stated position is that DMA-required changes introduce new risk: more avenues for malware, fraud, scams, and harmful content, plus reduced ability to intervene when things go wrong. In that framing, notarization and marketplace authorization aren’t “obstruction,” they’re the minimum necessary controls to keep iOS from turning into a mess of sideloaded ransomware and subscription traps.

For technical readers: you can disagree with Apple’s incentives while still acknowledging the engineering reality that every additional install channel expands the attack surface and complicates incident response.

3) Developers: “If the alternative path costs nearly as much, it’s not an alternative”

Developers and marketplace operators generally want two things at once:

• a distribution path that’s operationally sane (updates, entitlements, customer support expectations)
• economics that actually justify the overhead of running (or joining) a marketplace

The Setapp Mobile letter (as summarized by heise) points directly at sustainability problems under Apple’s terms.

The underlying concern: even if you can ship outside the App Store, you may still be living in Apple’s world—permissions, rules, audits, user-friction, and platform-defined cost structures. That can be fine; it’s just not the competitive reset people imagined.

4) Users/IT: “I want the App Store most of the time—until I don’t”

A lot of end users like the default App Store experience. The pressure for alternative distribution often comes from edge cases:

• an app category Apple rejects or restricts
• a business model Apple dislikes
• enterprise apps that don’t fit App Store norms
• power users who want nonstandard tooling

In org settings, IT/security teams may be even more conservative than Apple: they may ban third-party marketplaces to reduce risk, especially if MDM controls and audit logs aren’t as mature as what they already rely on.

So “more choice” can exist while adoption remains low—because trust and habit are powerful.

What’s genuinely new right now

A few things make this moment different from last year’s abstract DMA arguments:

• We have real-market outcomes, not just compliance documentation—e.g., at least one notable alternative marketplace is exiting.
• Apple’s position is now expressed as a product system, not just PR: notarization, marketplace authorization, disclosure flows, and EU-only scoping are built into the developer story.
• The debate is becoming measurable: number of viable stores, app catalog breadth, update reliability, support burden, fraud rates, and actual user uptake.

Risks and limitations (for everyone involved)

Security regressions are plausible, even with guardrails. Apple explicitly argues the DMA creates new avenues for malware and scams. Even if you think Apple is overstating it, the general pattern in software supply chains is clear: more channels, more complexity, more room for abuse.

User experience fragmentation is real. If payments, subscriptions, refunds, and account recovery vary per marketplace, support costs go up and trust goes down. This is exactly the kind of slow-burn friction that kills “alternative stores” even when they’re technically sound.

Economics can collapse before the ecosystem matures. Marketplaces need scale. If Apple’s terms (or the perception of them) make operators cautious, you can end up in a dead zone: not enough investment because there aren’t enough users; not enough users because there isn’t enough investment.

Geofencing creates product weirdness. EU-only behavior means engineers either ship region-specific logic or avoid the feature entirely. That’s not just policy overhead; it’s QA overhead and support overhead.

What to watch next

If you want early signals that iPhone distribution in the EU is becoming “real” (or not), watch these near-term milestones:

• Do credible, consumer-facing marketplaces survive past 2026 H1? The Setapp Mobile closure date (February 16, 2026) is an immediate marker.
• Do big developers commit? One or two mainstream names joining an alternative marketplace would matter more than dozens of tiny utilities.
• Do enterprises adopt third-party catalogs? If MDM vendors and large orgs start treating alternative distribution as normal, that’s a structural shift.
• Does Apple revise the terms again? Apple’s EU guidance frames the changes as risk-laden and evolving. If the European Commission pushes back, or if marketplace attrition continues, expect iteration—either simplification or further tightening.

Takeaway

Europe now has a technically workable path to iPhone app distribution beyond the App Store—but early evidence suggests the hard part isn’t enabling sideloading; it’s making an alternative ecosystem economically and operationally durable. The next chapter won’t be won in court filings or keynote slides. It’ll be won (or lost) in boring details: fees, update flows, customer support, security incidents, and whether users ever develop a reason to leave the default.Apple Has Weeks to Comply with EU Rules Forcing iPhone CompatibilityiPhone open only on paper: First app marketplace in EU closesUpdate on apps distributed in the European Union – Apple Developer

Something quiet but fundamental is happening in enterprise AI: we’re moving from “chat with a model” to let software act on your behalf.

Call them agents, copilots with tools, “agentic workflows,” or just automation with an LLM in the loop. The point is the same: the model isn’t only generating text anymore. It’s being asked to do things—query production databases, open tickets, change infrastructure, email customers, reconcile invoices, and chain multiple steps together until a goal is achieved.

That shift is why agentic AI is getting so much heat right now. It’s also why the debate is no longer mostly about model quality. It’s about control surfaces: permissions, provenance, audit, and what happens when an AI system becomes an insider.

What’s changing—and why it matters

Traditional genAI deployments are “read-mostly.” You paste a prompt, you get an output, and a human decides what to do next.

Agentic systems are “read-write.” They connect models to tools (APIs, shells, SaaS apps, internal services) and give them enough context to plan and execute multi-step work. In practice that means:

• Higher leverage: one person can orchestrate more operational work.
• Faster cycles: fewer human handoffs in routine tasks.
• New failure modes: mistakes aren’t embarrassing—they’re state-changing.

Security teams have a useful mental model here: an AI agent is like a digital insider with delegated access and the ability to act quickly at scale. That’s powerful when it’s aligned, authenticated, and constrained. It’s dangerous when it isn’t.

The real argument: how much autonomy is acceptable?

Under the “agents are the future” banner, there are at least four competing viewpoints—each reasonable, each incomplete.

1) “Let agents run—humans are the bottleneck”

This camp is usually product and platform leadership, plus teams drowning in toil. The thesis: most enterprise processes are already semi-automated, brittle, and slow. Agents can finally stitch together what humans do manually across UIs and ticket queues.

Their reasoning:

• The value comes from execution, not chat.
• If you force constant human approval, you lose the compounding benefit.
• The organization already trusts automation (CI/CD, auto-scaling, SOAR); agents are the next step.

The pushback they often underestimate: the moment an agent has real permissions, you’ve created a new attack surface and a new class of operational incidents.

2) “No autonomy without governance—or you’ll regret it”

This is the CISO / risk / compliance perspective. The thesis: the agent is not “just software.” It’s software that can be tricked (prompt injection, data poisoning), can hallucinate, and can leak or misuse data through tool calls.

Their reasoning:

• If an agent can read confidential data and write to systems, it must be governed like a privileged identity.
• Traditional app security assumes deterministic logic; agents are probabilistic.
• Without strong audit and least privilege, you’ll ship “automation” that incident responders can’t reason about.

This view is increasingly common as organizations report agent “risky behaviors,” including improper exposure and unauthorized access patterns.

3) “Keep it local: privacy-first compute is the only sustainable path”

A third camp is focused on privacy and data minimization: run more AI on-device or in tightly controlled environments, and avoid sending sensitive context to third-party clouds whenever possible.

Apple’s push with Private Cloud Compute is often cited as a sign of where the broader market could go: hybrid architectures that keep more processing private while still enabling heavier workloads when needed.

The tradeoff: local/private compute can constrain capability (model size, latency, tooling ecosystem), and “private” still needs rigorous verification and transparency to be meaningful.

4) “Regulation will force discipline (whether you like it or not)”

The governance debate isn’t happening in a vacuum. The EU AI Act is rolling in gradually over multiple years, with requirements and deadlines staged by risk level and category (including general-purpose AI model obligations).

The pro-regulation argument: compliance pressure will standardize risk management, documentation, and oversight.

The skeptical argument: regulation can lag implementation realities, and teams may end up optimizing for paperwork rather than real controls—unless enforcement and norms mature.

What’s actually new (not just rebranded automation)

A lot of “agents” talk is hype layered on old workflow engines. But a few technical shifts are genuinely new:

• Tool-using models as a platform primitive: structured function calling, retrieval, and multi-step planning are becoming default capabilities.
• Non-deterministic execution: you can’t fully predict the exact sequence of actions an agent will choose—even if you can constrain the space.
• UI-level agents: systems that operate via screenshots/DOM/app surfaces blur the line between automation and surveillance. Microsoft’s Recall controversy highlighted how fast “helpful memory” becomes a privacy debate, even when data is kept local and protected via opt-in and device security controls.

The tradeoffs most teams miss

Agents expand blast radius by default

If you connect an agent to email, file storage, ticketing, and infra, you’ve effectively given it a cross-system “integration user.” That account will accumulate permissions over time because it’s convenient—and convenience is how you end up with an always-on superuser.

Prompt injection becomes operational, not theoretical

In agentic setups, untrusted text isn’t only “input.” It can be instructions that redirect behavior. Think: a support email that contains adversarial text, or a webpage the agent reads that smuggles instructions into its context. When the next step is “call the tool,” the cost of being fooled jumps dramatically.

Auditing is harder than logging

Classic systems log API calls. With agents you also need to log:

• what the agent saw (inputs, retrieved context),
• what it decided (plan / intermediate reasoning in a safe form),
• what it did (tool calls),
• and why it believed it was allowed.

Without that, you can’t answer basic incident questions: “What did it read?” “What path led to this write?” “Was the instruction internal or injected?”

Human-in-the-loop is not a binary switch

Teams often frame oversight as either “approve every action” or “full autonomy.” In practice you want tiers:

• low-risk actions auto-execute,
• medium-risk actions require confirmation,
• high-risk actions require multi-party approval or are forbidden.

The hard part is deciding what’s “high risk” in your environment, and preventing gradual permission creep.

Risks and limitations (the unglamorous list)

• Privilege management: agents need identity, scoping, rotation, and revocation like any other privileged system—often more so.
• Data leakage: tool outputs can become model inputs; model outputs can become external messages. That’s a leakage pipeline if you’re not careful.
• Reliability: even with great models, multi-step workflows fail for mundane reasons (API changes, partial outages, edge-case data).
• Accountability: when something goes wrong, “the model did it” is not an answer regulators, customers, or incident reviews will accept.
• Shadow agents: teams will duct-tape agents to get work done faster. If central platforms don’t meet needs, agent sprawl will happen anyway.

What to watch next (near-term signals)

• Agent permissioning patterns that look like IAM, not app settings: if your “agent platform” doesn’t integrate with real identity/role systems, it’s not enterprise-ready.
• Standardized audit artifacts: expect pressure for “agent action logs” that are reviewable and exportable for compliance.
• More privacy-preserving deployment models: hybrid approaches (local + tightly controlled cloud) will become a differentiator, especially for regulated industries.
• Regulatory deadlines forcing governance maturity: EU AI Act staged implementation will keep pushing documentation, risk assessment, and oversight expectations into procurement checklists.
• Security guidance catching up: more playbooks focused specifically on agentic risk—treating agents as “digital insiders”—is already emerging.

Takeaway

Agentic AI is not just a bigger chatbot. It’s a new kind of integration layer—one that can act, and therefore can break things.

If you’re piloting agents today, the winning approach is neither “ship autonomy everywhere” nor “ban it until it’s perfect.” It’s to treat agents like privileged automation: least privilege, tiered approvals, strong auditability, and clear boundaries between untrusted input and authorized actions. The teams that internalize that early will get the productivity upside without turning their next incident report into an AI morality play.AI Act implementation timeline | Think Tank | European ParliamentImplementation Timeline | EU Artificial Intelligence ActEU AI Act News 2026: Compliance Requirements & Deadlines

AI agents are escaping the chat box and moving into your browser, your inbox, and your SaaS admin console.

Not as sci‑fi “autonomous coworkers,” but as action-taking software that can click through UIs, read internal docs, draft the email, file the ticket, and (sometimes) push the button. The hook is obvious: if your team spends hours a week on “glue work,” agentic tools promise to compress that into minutes. The catch is equally obvious: the moment an LLM can act, the risk profile stops looking like “bad answer in a chat” and starts looking like “bad change in production.”

This shift is no longer hypothetical. OpenAI rolled “agent mode” into ChatGPT in mid‑2025, explicitly combining web navigation with research-style synthesis and connectors to third-party tools. Anthropic shipped “computer use” in public beta for Claude in late 2024, giving models mouse/keyboard control via screenshots. Google is pushing a parallel idea in Workspace Studio: no‑code “agents” that can trigger across Gmail/Drive/Chat and connected apps.

What’s changing—and why it matters

We’re moving from LLMs as advisors to LLMs as operators.

A conventional chatbot can hallucinate, but it can’t directly open your admin console and rotate keys. An agent can. Even when it’s “kept under user control,” the control surface changes: instead of “approve this paragraph,” you’re approving workflows and side effects.

That matters for three practical reasons:

1. Permission boundaries get fuzzier. Agents live where your work lives—email, docs, ticketing, calendars, internal wikis, browsers. Those are already privileged environments.
2. The attack surface expands to “anything the agent can see.” Web content becomes executable instructions through prompt injection and UI manipulation—especially when the agent is reading pages and taking actions in the same loop.
3. Reliability becomes a systems problem, not a model problem. The real question isn’t “is the model smart?” It’s “can we constrain it, audit it, and recover when it does the wrong thing?”

Security folks have been waving the red flag here, tracking an emerging cluster of agent-specific failures (prompt injection, data exfiltration, and “memory” abuse) as these tools head into production.

The real argument isn’t “agents: good or bad”

The debate is over how we deploy them, and what kind of failures we’re willing to tolerate.

Viewpoint 1: “Agents will be the new UI layer—ship them now”

Proponents see agents as a pragmatic next step: workflows are already fragmented across tabs and tools, and employees already copy/paste between systems. If an agent can unify that mess—read context from docs, pull numbers from spreadsheets, draft the update, file the ticket—then the productivity upside is immediate.

This camp tends to believe:

• Most tasks are reversible (drafts, summaries, tickets).
• Human-in-the-loop approvals are “good enough.”
• Early adoption creates compounding advantage (faster execution, less ops drag).

Google’s pitch for Workspace Studio fits here: agents as a no-code automation layer deeply integrated into the apps people already use.

Viewpoint 2: “Agents are risky because the web is hostile”

Security researchers (and many enterprise defenders) treat action-taking agents as a new endpoint class: they browse untrusted content and possess privileged sessions (cookies, tokens, access to connected apps). That combination makes classic web threats more dangerous, because the agent can be tricked into doing the attacker’s work.

The key concern: indirect prompt injection—instructions embedded in a page, doc, or email that the agent treats as higher priority than the user’s intent. Some industry writeups have cataloged attack patterns and disclosures across “agentic browsers” and tool-using assistants over 2025.

This camp tends to push for:

• Strict allowlists (domains, actions, data sources)
• Sandboxed execution (separate profiles/VMs)
• Minimal privileges and short-lived tokens
• Default-deny for “meaningful” actions (purchases, account changes, data exports)

Anthropic’s own “computer use” documentation leans heavily on isolation and limiting access to sensitive data, especially when interacting with the internet.

Viewpoint 3: “Tooling beats autonomy—agents should call APIs, not click UIs”

A quieter, more engineering-centric stance: the flashy demos (agents clicking around websites) are the worst way to automate serious work. UIs are brittle, visual grounding is imperfect, and every click is an opportunity for misinterpretation.

Instead, build agents that:

• Use typed tools (APIs with schemas, constraints, validation)
• Operate on structured data whenever possible
• Treat UI automation as a last resort

In other words: the “agent” is an orchestration layer; the real work happens through well-defined interfaces with guardrails. This view often correlates with higher success rates in production because failures are catchable (bad parameter, failed validation) rather than ambiguous (“the agent clicked the wrong button”).

Viewpoint 4: “This is mostly a compliance and governance problem”

For IT and risk teams, the largest blocker isn’t whether agents can do the task—it’s whether the organization can explain and control what happened.

They care about:

• Audit logs (what data was accessed, what actions were taken)
• Data residency and retention (especially with connectors)
• Identity and access management alignment (SSO, least privilege)
• Approval workflows and policy enforcement

OpenAI’s positioning of ChatGPT’s agent mode as “keeping you in control” speaks to this, but the details matter: what’s logged, what can be disabled, what can be scoped.

What’s actually new (beyond the hype)

A few concrete developments make “agents” feel different from last year’s copilots:

• Integrated action + research loops. Tools that both browse/synthesize and then act (fill forms, edit spreadsheets) reduce the friction that used to keep LLMs “read-only.”
• Desktop/UI control shipping in mainstream APIs. “Computer use” isn’t a research demo anymore; it’s an exposed capability with docs, versioning, and explicit safety guidance.
• No-code agent builders inside productivity suites. This moves agent creation from “AI platform team” to “any power user,” which is both the growth engine and the governance nightmare.

Risks and limitations (the ones that bite in production)

1. Indirect prompt injection is not a corner case. Any agent that reads untrusted text/images and then takes actions is exposed. This includes emails, shared docs, ticket descriptions, and web pages. Security teams are already treating this as a first-class issue for “agentic browsing.”

2. Over-broad connectors turn “helpful” into “over-privileged.” Connect Gmail/Drive/GitHub/Jira and you’ve created a high-value target. Least privilege becomes harder when the agent’s job is “help with everything.”

3. UI automation is inherently flaky. Layout changes, A/B tests, pop-ups, cookie banners, and subtle visual ambiguities cause failure modes that are hard to test and reproduce.

4. Human-in-the-loop can become rubber-stamping. If an agent produces ten “ready to send” actions in a row, reviewers stop thinking critically—especially under time pressure.

5. “Memory” and persistence complicate recovery. If an agent stores long-term preferences or context, you need to treat that store like configuration: version it, audit it, and have a reset story. Some security discussions now explicitly call out “memory persistence” as an emerging risk category for LLM apps.

What to watch over the next 3–6 months

• Do vendors default to sandboxing, or make it optional? Look for hardened “agent runtimes” (separate browser profiles, VM isolation, scoped tokens) becoming the default rather than the enterprise add-on.
• Policy and auditability features catching up to capability. The competitive edge may shift from “my agent can do more steps” to “my agent can prove what it did.”
• Allowlisting and “restricted tool” patterns becoming common. Expect more deployments where agents can only operate within a constrained set of domains, apps, and actions.
• A split between consumer agents and enterprise agents. Consumer tools will optimize for autonomy and convenience; enterprise tools will optimize for controllability and liability reduction.

Takeaway

Agentic AI is crossing the line from “text generator” to “operator of real systems,” and that’s why the debate is so heated. The winners won’t be the agents that look most human—they’ll be the ones that are most governable: constrained permissions, auditable actions, safe defaults, and a clear blast-radius story when (not if) something goes wrong.Gemini Enterprise: Best of Google AI for BusinessGoogle launches Workspace Studio to create Gemini agentsGoogle Workspace Updates: Now available: Create AI agents to automate …