Artificial Lawyer ran a piece this week on accountability by design in agentic contract management, and it puts a name on something we keep running into in agent pilot conversations: nobody’s real objection to contract agents is capability. The objection is that when the agent does something wrong, nobody can say who owns it.

That’s the right objection. And it’s fixable, but only if you treat accountability as an architecture decision instead of a policy memo.

Why contracts are the hardest room in the building

Think about what a contract agent actually touches. It reads negotiated terms. It proposes redlines. It extracts obligations and renewal dates and feeds them downstream to finance and ops. In more ambitious deployments it drafts counterparty emails or kicks off approval workflows on its own.

Every one of those actions has a legal consequence attached. A missed auto-renewal clause isn’t a bug ticket, it’s money. A redline that quietly softens an indemnification cap is malpractice territory if a human never saw it. Contracts are where the gap between “the model was 94% accurate” and “we are liable for the 6%” stops being abstract.

So when a GC asks “who is accountable when the agent errs,” the answer cannot be a shrug toward the vendor’s terms of service. The answer has to be visible in the system itself.

What accountability by design looks like when you build it

Here is what we mean when we talk about AgentWorks-style oversight, in concrete terms:

Every action is logged, and the log is legible. Not a JSON dump an engineer can grep. A record a lawyer can read: what the agent did, when, on which document, based on which instruction, with what confidence. If your audit trail requires a data scientist to interpret, you don’t have an audit trail. You have exhaust.

Permissions are scoped per agent, per task. The agent that extracts renewal dates does not get write access to the redlining workflow. The agent that drafts counterparty emails cannot send them. Least privilege isn’t a new idea. Legal teams have run it on humans for a century through signing authority and matter permissions. Agents deserve the same treatment, and honestly, it’s easier to enforce on software than on a partner who’s in a hurry.

Human gates sit at defined thresholds, not everywhere and not nowhere. Blanket “human reviews everything” defeats the point of the agent. Blanket autonomy defeats the point of having a legal department. The useful middle: the agent handles routine NDA turns solo, but anything touching liability caps, IP assignment, or dollar figures above a set line stops and waits for a named person. That threshold is a dial your team sets. It should live in a dashboard, not in a prompt somebody wrote in March and forgot about.

Escalations name a human. When the agent hits its confidence floor or its permission ceiling, the handoff goes to a specific person with a deadline, and the dashboard shows aging escalations the way a docket shows deadlines. Accountability that doesn’t attach to a name isn’t accountability.

You can replay the decision. Six months from now, when a counterparty disputes a term, you need to reconstruct exactly what the agent saw and suggested and what the human approved. Versioned inputs, versioned outputs, versioned instructions. This is the part most pilots skip and most regret.

None of this is exotic. It’s the same discipline legal ops already applies to matter management and billing approval, extended to a new kind of worker.

The part the article gestures at but doesn’t say out loud

There’s a quieter question under all of this: where does the oversight layer itself live?

If your agent runs inside someone else’s cloud, on someone else’s logging, under someone else’s retention policy, then your accountability story has a hole in it shaped exactly like your vendor. You can’t produce audit records the vendor didn’t keep. You can’t enforce a permission boundary the platform doesn’t expose. You can’t guarantee the contract text that flowed through the agent never trained anything, because that guarantee was never yours to make.

Your data, your rules. And in an agentic system, that has to include agency over the AI working on that data. Your AI, your rules. The oversight dashboard, the action logs, the escalation thresholds, all of it should sit on infrastructure you control, governed by policy your team wrote, auditable without asking anyone’s permission. For a legal team this isn’t a philosophical preference. Privilege and confidentiality obligations follow the documents wherever they go. An agent architecture that can’t answer “where did the contract text travel” hasn’t earned the word accountable.

This is where we think agent pilots should start, by the way. Not with the flashiest use case, but with the use case where the oversight scaffolding is easiest to prove out. Run the renewal-date extraction agent first, watch the logs, tune the escalation thresholds, let the team build trust in the dashboard. Then move up to redlining. The scaffolding is the product. The agent is just the first tenant.

The grounded version

The Artificial Lawyer piece is right that accountability has to be designed in, not bolted on. Where I’d push further: designed in means owned. Owned logs, owned permissions, owned thresholds, owned infrastructure. A vendor can sell you an agent. Nobody can sell you accountability. That one you have to hold.

If you’re running or scoping a contract agent pilot right now, I’m genuinely curious: where did you set the line between what the agent does alone and what waits for a human, and how did you pick it? That threshold decision is the whole design in miniature, and I’d like to hear how it’s playing out at your firm.

The post Accountability by design is the only way contract agents get hired appeared first on Modular Technology Group.

The Register ran a piece this week that a lot of IT leaders will nod along to: digital sovereignty sounds great until you try ditching your suppliers. The gist: everyone in Europe and beyond is suddenly talking about controlling their own data, their own infrastructure, their own destiny. Then they open the hood, see fifteen years of accumulated dependence on two or three hyperscalers, and quietly close it again. Migration is expensive. The skills aren’t there. The integrations run deep. Sovereignty, the article suggests, is a nice speech and a brutal project plan.

The article is right about almost everything, and it still draws the wrong lesson.

The pessimism is earned, but it’s pessimism about retrofitting

Read the piece carefully and notice what every hard case has in common. The organizations struggling aren’t struggling with sovereignty. They’re struggling with reversal. They built for a decade on someone else’s platform, using someone else’s proprietary services, on someone else’s contract terms, and now they want to walk it back. Of course that’s painful. You’re not adopting an architecture at that point. You’re performing surgery on a live patient who’s been fused to the operating table.

Egress fees are the obvious villain, and yes, they’re real money. But egress is the small problem. The big problem is that most cloud-native systems weren’t designed to run anywhere else. When your app logic is welded to a hyperscaler’s managed queue, its identity service, its serverless functions, its specific flavor of managed database, the data can technically leave. The system can’t. You’d be rewriting, not migrating.

So when a CIO says “sovereignty is too hard,” what they usually mean is “unwinding my last ten years of decisions is too hard.” True. Also not an argument against sovereignty. It’s an argument against how they got here.

Lock-in is a design choice you made, whether you noticed or not

Nobody signs a contract titled “Dependence Agreement.” Lock-in accretes. A team picks the managed service because standing up the open equivalent would take three sprints. A vendor discount ties renewal to consumption commitments. A compliance officer signs off on a region, and suddenly the region is load-bearing. Each decision was locally rational. The sum is a company that can’t leave.

The fix isn’t a heroic exit project scheduled for some future fiscal year when things calm down. Things never calm down. The fix is refusing to accumulate the dependence in the first place, and that has to happen at the architecture stage, on day one, when it’s cheap.

What does that actually look like? Concretely:

Own the physical layer or contract it in a way you can walk away from. Know which building your data sits in and under whose legal jurisdiction. If the answer involves a foreign court’s subpoena power, you don’t have sovereignty, you have a hopeful arrangement.

Pick portable primitives. Containers over proprietary serverless. Open protocols over vendor SDKs. Standard databases over managed ones with quirks you’ll only discover during a migration. Boring choices, deliberately.

Stay model-agnostic on the AI side. This is the newest lock-in vector and the fastest-growing one. Teams are currently wiring their workflows to one frontier model’s API the same way teams in 2012 wired everything to one cloud’s services. Same movie, faster projector. If your prompts, your pipelines, and your evaluations only work against one vendor’s endpoint, you’ve rebuilt the exact trap The Register is describing, except this time the vendor can change the model underneath you without asking.

Fix your costs. Variable consumption pricing is itself a control mechanism. When leaving means eating an unpredictable bill, the pricing model is doing the lock-in work the technology doesn’t have to.

None of this is exotic. It’s just unfashionable, because every step trades a little short-term convenience for long-term freedom of movement, and short-term convenience has been winning that trade for fifteen years. The Register piece is the invoice arriving.

We’re biased, and here’s why

Modular builds private AI infrastructure end to end, from the physical facility up through the interface people actually use. From dirt to desktop, on US soil, at fixed pricing, running whatever models fit the client’s needs rather than whichever vendor bought us lunch. So yes, we have a horse in this race.

But the reason we built it that way is precisely the failure mode in this article. We watched organizations try to bolt sovereignty onto architectures that were never meant to grant it, and we watched the retrofit cost kill the initiative every time. The only version of sovereignty that survives contact with a budget meeting is the version that was there from the start, when portability cost nothing extra because it was simply how the system got built.

Your data, your rules. That’s the whole thesis, and it only holds if “your rules” is enforced by the architecture instead of promised by a contract. A sovereignty clause in an MSA is a rule the vendor agreed to follow. A stack you control is a rule nobody has to follow, because there’s no one else in the room.

The honest takeaway

If you’re deep in a hyperscaler today, the article’s pessimism is fair warning: don’t announce a grand exodus you can’t fund. Rank your workloads by how trapped they are. Move the portable ones. Stop the bleeding on new builds by making them portable by default. Sovereignty regained incrementally beats sovereignty announced and abandoned.

And if you’re starting something new right now, an AI initiative, a new product line, a greenfield system, you have a choice the retrofitters would kill for. You can build on ground you own. The cost of doing it from day one is small. The cost of doing it in year ten is the entire subject of that Register article.

So here’s what I’d genuinely like to know from people running infrastructure right now: if you had to move your most important workload off its current platform in twelve months, what’s the first thing that would break? Not hypothetically. Name it. That answer tells you more about your sovereignty posture than any strategy deck, and I’d like to hear it.

The post Sovereignty isn’t an exit plan. It’s a floor plan. appeared first on Modular Technology Group.

The Hacker News ran a piece this week on “shady AI” as security’s next big governance problem, and the framing is right even if the nickname is a little cute. The short version: employees are using AI tools nobody sanctioned, nobody logged, and nobody can audit, and security teams are discovering it the same way they discovered shadow IT fifteen years ago. After the damage.

I want to push on one part of that story, because I think the industry keeps drawing the wrong lesson from it.

We’ve seen this movie, and we handled it badly the first time

Around 2011, Dropbox showed up on every corporate laptop in America without a single procurement meeting. IT departments responded with the only tool they had: blocking. Employees responded the way employees always do. They found another sync tool, then another, then they just emailed files to their personal Gmail. The data left anyway. It just left through channels nobody could see.

Shadow AI is that story with higher stakes and a faster clock. A paralegal pastes a client’s settlement draft into a free chatbot to “tighten the language.” An analyst uploads the quarterly pipeline to get a summary slide. A developer feeds proprietary code into a coding assistant on a personal account because the corporate one has a waiting list. None of these people think they’re exfiltrating data. They think they’re doing their jobs faster, and honestly, they are.

Here’s the uncomfortable part. When you block the tool without offering a sanctioned alternative, you don’t stop the behavior. You just push it onto personal devices and personal accounts, where your DLP tooling, your logs, and your retention policies mean exactly nothing.

The real gap is that nobody owns this

Read the incident reports behind these stories and a pattern shows up fast. It’s rarely a technology failure. It’s an ownership failure.

Ask a mid-sized firm “who owns AI here?” and you’ll get one of four answers:

1. The CISO, who treats it purely as a threat surface and defaults to no
2. The CIO, who treats it as a procurement question and defaults to whatever the incumbent vendor bundles in
3. A volunteer “AI champion” with enthusiasm and no authority
4. Nobody

All four produce shadow AI. The CISO’s blanket “no” produces it fastest, because demand doesn’t disappear when you deny it. Demand goes underground.

What actually closes the gap is a role most companies under a few thousand employees can’t justify hiring full time: someone with the authority to say yes to specific tools under specific conditions, the technical depth to evaluate what a vendor actually does with your prompts and outputs, and the standing to write policy that survives contact with the legal department. A Chief AI Officer, in other words. Which is exactly why the fractional version of that role exists, and why we’ve built our practice around it.

What “sanctioned” actually looks like

A fractional CAIO engagement done right isn’t a policy PDF that ships in week two and dies in a SharePoint folder. It’s a working AI Program Office, even a small one, and it does a few unglamorous things well.

It builds an inventory first. You cannot govern what you can’t see, and most organizations are shocked at their own numbers. Egress logs and expense reports tell the truth: the tools are already in the building. Start from reality, not from the org chart’s fiction.

Then it gives people a legitimate path. An approved model catalog, provisioned accounts with enterprise data terms, and clear rules about what data classes can touch what tools. When the sanctioned option is good and available, the shadow option loses most of its appeal. People weren’t choosing the risky tool because they loved risk. They were choosing it because it was the only one that worked.

Then it keeps watching. Usage dashboards, periodic review of what’s flowing where, an actual human accountable when the answer to “where did that document go?” needs to be produced for a regulator or a client. Governance is a verb. You do it continuously or you’re not doing it.

And underneath all of it sits an architectural question the article gestures at but doesn’t quite land: where does the model run? For a lot of the data that leaks through shadow AI, the honest fix is not a better vendor contract. It’s inference that runs on infrastructure you control, where prompts and outputs never leave your environment and no third party’s retention policy is part of your threat model. Your data, your rules, and that includes the AI working on it. Your AI, your rules. Governance you can’t verify at the infrastructure level is governance you’re taking on faith.

The window for doing this cheaply is now

Every month of unmanaged use is training data you can’t claw back, client information sitting in some vendor’s logs under terms nobody read, and habits getting harder to redirect. The organizations that treated shadow IT as a demand signal in 2012, and built sanctioned answers, came out with better tooling and fewer breaches than the ones that fought a blocking war for five years. Same fork in the road here, shorter runway.

So here’s what I’d genuinely like to know from anyone running security or ops at a firm right now: have you actually looked? Pulled the egress logs, checked the expense reports, asked the question in an all-hands where people could answer honestly? And if you did, what did you find versus what you expected? Tell me below. The gap between those two numbers is the whole story.

The post Shadow AI isn’t a user problem. It’s a missing-owner problem. appeared first on Modular Technology Group.

Most companies did not choose an AI strategy. They chose a model, and the strategy grew up around it.

A piece on Towards AI this week, The Durable Asset is the Control Plane, not the Frontier Model, puts that habit on trial. The author’s evidence is Cursor, the coding tool that became one of Anthropic’s largest customers while Anthropic’s own coding agent increasingly competed with it at the application layer. Cursor meanwhile built upward: its own models, its own agent runtime, and in July a router that decides which model sees each request. The article’s conclusion is blunt: the durable asset is the control plane above the model, the layer that holds policy, spend, identity, and evaluation so no single vendor can hold them for you. The model itself is replaceable.

At Modular Technology Group we agree, and we would push it one step further for the companies we work with. That layer is where “your data, your rules” has to live, because the rules do not survive anywhere else.

The layer nobody bought

The article describes four layers. Models are the specialists. A router decides which specialist sees which request. A harness is the runtime around the model: tools, files, memory, permissions, the loop that turns tokens into actions. And a meta-harness sits above all of that so harnesses and models can be swapped without rewriting anything. Databricks has open-sourced one, and its hosted version is in beta as of this month.

The author’s analogy is a hospital. Nobody sends every patient to the most expensive specialist. Primary care handles the predictable cases, triage decides who goes where, and the hospital system supplies identity, budgets, records, and oversight across all of it. Then comes the line worth taping to a monitor: most companies bought a specialist and never built a hospital.

Picture a forty-person firm. Someone signed up for a frontier chat tool two years ago. It worked, so more people used it. Prompts now carry client matters and payroll data. Nobody can say what it costs per month across the seats, which model version answered a given question, or what happens to the account when the vendor ships a product that competes with the firm’s own service. There is no router, since there is only one model, and the policy is whatever the vendor’s terms of service say this quarter. The firm has an excellent specialist and no hospital.

Routing is a governance decision wearing an engineering hat

It is tempting to read the article as advice for platform teams at large companies, since the examples are Cursor, Snowflake, Microsoft, and NVIDIA. The routing products those companies ship are real, and the article is careful about their fine print: some routers require a specific model to be enabled, and curating a model list can shrink your effective context window to the smallest model in the set. The author’s advice is to ask every routing vendor which models are mandatory before assuming the layer is provider-neutral.

But strip the vendor names away and routing is a question a small firm can answer today. Which of our work is routine and easy to check? Which of it is novel, or high enough stakes that a person should sign off? The first bucket can run on a validated open-weight model on hardware you control, at a fixed cost, with the data never leaving the building. The second bucket earns the frontier model. The third bucket, the high-stakes one, gets verification and a human approval regardless of which model answered.

Odds are your firm has never measured its own split. That measurement is where a governance engagement should start, and the point of doing it first is that nobody buys anything until the split is on paper. The article’s phrase for the payoff is refusing to spend frontier dollars on work a cheaper, validated model already handles. Read that as a policy statement rather than a cost tip, because once the routing rule enforces it, the policy holds without anyone re-reading a memo.

Your data, your rules, and that includes the AI working on it. Your AI, your rules. The router is where the second half of that gets enforced.

What to own, and what to rent

The article closes with a list of what the durable asset actually contains: models that can change without a rewrite, routing that can learn, harnesses that can be substituted, policies that follow the workload, identity and budgets that stay centralized, and evals that prove the system is improving. It also notes that only operationally mature teams pull this off, because you need evals that say which work is safe to route cheaper, and policy that is not a prompt.

For a small or mid-sized firm, that list is a buy-versus-own map. Rent the specialists. As the article says, models will keep changing and prices will keep moving, so there is no reason to be loyal to one. Own the hospital. The gateway that every request passes through, the budget that caps a runaway agent, the log that says which model answered which question with whose data, and the routing rule that keeps client records on infrastructure you control. Those are small pieces of software. They are also the only pieces you cannot afford to have a vendor hold for you. When the vendor’s incentives shift, that layer is what lets you leave on your own terms.

You do not need Databricks or a platform team to get there. You need someone accountable for the question, a private environment where routine work can run, a gateway in front of everything else, and the discipline to measure cost per finished task rather than cost per token. That is the stack we design for firms that are too small for an enterprise AI program and too regulated to keep improvising, and the order of operations is the whole method. Policy first. Then routing. Then, and only then, the model.

So here is the question for your own shop. If your frontier vendor announced tomorrow that it now sells what you sell, which parts of your AI setup would you keep, and which would you be renting back? Tell me what that inventory looks like at your firm.

The post Pick the model last appeared first on Modular Technology Group.

Google spent the better part of a year telling everyone that Antigravity, its agentic coding environment, was the future of software work. Agents that plan, write, test, and ship with a human somewhere in the loop, loosely defined. Last week The Register reported that Google is now tethering Antigravity to its enterprise admin controls. Policy enforcement, permission scoping, audit visibility, the works.

Read that again. The company with more AI research muscle than almost anyone on the planet looked at its own autonomous agents running inside customer environments and decided they needed a leash.

That’s not a product announcement. That’s an admission.

What the tether actually tells you

For roughly two years the agentic AI pitch has been velocity. Let the agent touch the repo, the ticket queue, the database, the deployment pipeline. Trust the model. Move fast.

Enterprises, it turns out, were not buying it at scale. Security teams kept asking the same unglamorous questions. What can this agent read? What can it write? Who approved that? Where’s the log? And the honest answer, for most agentic tools shipped since 2024, was some version of “we’re working on it.”

So Google did what a vendor under pressure does: it built the controls its buyers were demanding and wired them into the Google admin plane. Good for Google. Genuinely good for Antigravity customers, too, in the narrow sense. An agent with scoped permissions and an audit trail beats an agent without them every single day.

But notice where those controls live. Inside Google’s console, expressed in Google’s policy language, enforced by Google’s infrastructure, covering Google’s agents. If you run Antigravity plus a Copilot deployment plus a homegrown agent on an open-weights model, and most mid-size shops we talk to are already in exactly that mixed state, you now have one well-governed island and a lot of open water.

Governance rented from a vendor is still lock-in

Here’s the part that should bother you more than the ungoverned agents did.

When your AI governance is a feature of one vendor’s platform, your policy layer becomes a switching cost. Every rule you write in their console, every approval workflow you build around their audit log, every compliance attestation that cites their controls, all of it deepens the moat around that one product. Leave the product and you leave your governance behind. You’d have to rebuild it from scratch inside the next vendor’s console, in their language, with their gaps.

That’s a strange place to park something as load-bearing as “who is allowed to let software act on our behalf, and under what conditions.”

Governance isn’t a feature. It’s a function. It belongs to the organization, above the tools, the way your security policy isn’t a setting inside your firewall vendor’s dashboard. The firewall enforces the policy. It doesn’t own it.

What owning it looks like

This is exactly the problem a fractional Chief AI Officer, or a small AI Program Office if you want the standing version, exists to solve. Not a committee that meets quarterly and produces a PDF. A working function that does specific things:

• Keeps an inventory of every agent and model in use, sanctioned or not. Most orgs that build this list for the first time find two or three tools nobody in leadership knew about.
• Writes permission and data-access policy once, in plain language the business owns, then maps it onto each platform’s controls. Google’s tether becomes one enforcement point among several, instead of the whole strategy.
• Defines what gets logged, reviewed, and escalated when an agent acts, regardless of whose agent it is.
• Maintains an exit plan per vendor. If the policy layer is yours, swapping the tool underneath is an engineering project, not an identity crisis.

None of this requires a full-time executive salary, and at most firms it shouldn’t get one. It requires a few disciplined days a month from someone who has done it before and answers to you, not to a platform’s roadmap.

The alternative is what we’re watching play out now: each hyperscaler ships its own governance surface, each one slightly different, and enterprises stitch together a compliance story out of four vendors’ screenshots and hope the auditor doesn’t ask how the pieces relate.

The principle underneath

Modular’s position on data has been the same since day one. Your data, your rules. And that includes the AI working on it. Your AI, your rules. An agent that can read your files, write your code, and act in your name is not a productivity toy. It’s an actor inside your business, and the rules governing an actor inside your business should be written by you, enforceable everywhere, and portable to whatever stack you run next year.

Google tethering Antigravity is a milestone worth marking, because it settles the argument. Ungoverned agentic AI is untenable, and now even the people selling the agents say so out loud. The open question is only who holds the tether. The vendor, or you.

We think the answer is obvious, and we think it’s a solvable, medium-sized project rather than a moonshot. Most of the firms we work with get a real inventory, a written policy, and enforcement mapping in place within a quarter.

So here’s what I’m curious about. If an auditor walked in tomorrow and asked you to list every AI agent with write access to something that matters in your business, how long would that list take to produce, and who in your org would have to produce it? Tell me honestly. The answers I’ve heard so far range from “ten minutes” to “we’d have to send an all-staff email,” and the gap between those two companies is the entire story.

The post Google put a leash on Antigravity, and that’s the whole story appeared first on Modular Technology Group.

No news this week. One argument instead, built from the ground up, because it is the place our reporting keeps landing and it has earned a hearing on its own. AI governance, for a business your size, is four things. An owner. A boundary. A log. And evidence. That is the entire list.

In this episode

• Who owns this? Not who bought it, and not who is good with computers: who is accountable when it goes wrong. Software with no owner does not sit still, it spreads. The fix costs nothing. One name next to one tool, and it can be a name already on your organization chart.
• Where does it end? A boundary is not a fence around the tool. It is a sentence about your material: what this is allowed to touch, and what it is not. Two lines is a real boundary. Then the harder half: where does your material go while the tool is looking at it? If it has to stay inside your walls, the tool has to run inside your walls.
• What happened? The log, and the one design choice that decides whether it is worth keeping: give the software its own identity. If your AI runs on an employee’s credentials, then in your own logs the software and the employee are one actor, and you cannot answer the only question anybody asks afterward.
• Can you show it? Not describe it. Show it. The name of the owner, the sentence about the boundary, a month of the log. Evidence is cheap to keep and impossible to build backwards. Nobody has ever manufactured last quarter.

The question we asked

Pick any AI tool in your business and answer question one out loud. Who owns this? If a name comes easily, you are further along than you think. If it does not, you have just found this month’s work. Get the Modular Briefing by email and reply to it, or write to Arthur at arthur@modtechgroup.com. A person reads every reply.

A note on this edition

This edition cites no news and no outside sources, on purpose. It is the argument the news editions keep arriving at from different directions, made directly. Nothing in it goes stale.

A note on the voices

Laura and Arthur are AI-generated voices, produced locally on Modular’s own infrastructure. The editorial judgement and script are the work of the Modular team.

Transcript

Your data, your rules.

The post The Modular Briefing, September 3, 2026: What Governance Actually Asks For appeared first on Modular Technology Group.

Spirit Airlines needed money. Google, according to the flight attendants’ union, wanted something more interesting than interest payments.

Fortune reported last week that the Association of Flight Attendants is accusing Google of structuring a deal around Spirit’s restructuring that would hand the tech giant access to confidential airline data for AI purposes. The union’s language was blunt. “Adding insult to injury” is how they framed it: their employer is in financial distress, their jobs are uncertain, and now the data generated by their work might get folded into someone else’s model training as a side effect of a transaction they had no seat at.

Set aside for a moment whether the union’s characterization holds up in every detail. The shape of the deal is the story. And the shape is one we’re going to see again and again.

Data as the sweetener

When a company is healthy, its data sits behind contracts, policies, and a general reluctance to give anything away. When a company is desperate, all of that becomes negotiable. Data turns into an asset on the table, right next to the gates and the aircraft leases. A lender or strategic partner who wants training data doesn’t have to buy it on the open market. They can attach it to financing that the company can’t afford to refuse.

Notice who’s missing from that negotiation. The flight attendants whose schedules, communications, performance records, and operational patterns make up a real chunk of that “confidential data” were not in the room. They didn’t sign up for it when they took the job. There was no consent moment. Their information became a bargaining chip because it happened to be sitting in systems their employer controlled and their employer needed cash.

That’s the part that should make every executive uncomfortable, and not only on behalf of the workers. Flip the seats. Your company’s data is sitting in a vendor’s cloud right now. That vendor has its own investors, its own pressures, its own potential acquirers. If your vendor hits a rough patch, or gets bought, or signs a strategic partnership with an AI lab, what stops your data from becoming their sweetener?

Read your agreements. In most cases the honest answer is: less than you think. Terms of service change. “Improving our services” clauses stretch. Acquisitions transfer data along with everything else, and the successor company’s appetite may not match the original vendor’s promises.

Consent doesn’t survive the deal

Here’s the mechanism worth naming plainly. Consent, in most data arrangements, is a snapshot. An employee consents to an HR system. A company consents to a cloud provider’s terms. Then the world moves. The provider changes hands, the terms get amended, a financing deal introduces a new party with new incentives. The original consent never contemplated any of it, but the data doesn’t get re-asked. It just flows to wherever the paperwork now permits.

The Spirit situation makes this vivid because a bankruptcy court and a union give it visibility. Most versions of this story never get a headline. The data quietly gains a new downstream use, a new processor, a new training pipeline, and nobody with standing to object ever finds out.

For firms handling client files, patient records, case materials, or workforce data, this should reframe the vendor question entirely. The question is not “do I trust this vendor today.” It’s “do I trust every future owner, creditor, and strategic partner of this vendor, under financial conditions I can’t predict.” Nobody can answer yes to that honestly.

The only clean answer is architectural

You can’t contract your way out of this. You can architect your way out of it.

If the AI workload runs inside infrastructure you control, on hardware in a known jurisdiction, with models you selected and can swap, there’s nothing for a third party to acquire access to. There’s no pool of your data sitting in someone else’s cloud waiting to become deal collateral. A vendor’s bankruptcy, acquisition, or creative new financing arrangement can’t repurpose data it never touched.

That’s the entire premise behind private AI workspaces as we build them at Modular. Client data and workforce data stay inside the client’s environment. Models run locally. Nothing feeds a third-party training pipeline, not because a policy says so, but because there’s no pipe. We own the stack from the physical facility to the interface the user touches, which means there’s no intermediate layer where someone else’s business model can intervene. Your data, your rules, from dirt to desktop.

And because the pricing is fixed, there’s no meter running that tempts anyone, us included, to find secondary value in what flows through the system. The economics are aligned with the architecture. You pay for capability, not for the privilege of becoming training data.

The flight attendants understood something instinctively that a lot of boardrooms still haven’t internalized: once your data is in someone else’s hands, your interests and theirs will eventually diverge, and when they do, the paperwork will favor whoever holds the servers.

The closing thought

I keep coming back to the phrase “adding insult to injury.” The injury was the financial distress. The insult was discovering that your working life had a resale value you never agreed to. Spirit’s flight attendants at least have a union loud enough to get this into Fortune. Most employees, and most companies whose data is riding in third-party clouds, will never get the courtesy of a headline.

The uncomfortable exercise for this week: pull up your top three data-holding vendors and try to answer, from the actual contract language, what happens to your data if they’re acquired or restructured. If you’ve done that exercise, or if you think I’m overreading the Spirit deal, tell me what you found. I’d genuinely like to compare notes.

The post When the financing comes with a data clause appeared first on Modular Technology Group.

The Register ran a piece this week that should get more attention than it will: Salesforce partners are reportedly not seeing meaningful revenue from Agentforce. Not customers grumbling. Partners. The consultancies and integrators who staffed up practices, sat through the certifications, and built their 2026 pipeline around Marc Benioff’s favorite word.

That detail matters more than another “AI pilot stalls” headline would. Partners are the canary in any enterprise software ecosystem. They only make money when customers actually deploy, expand, and renew. When a vendor’s sales numbers look fine but the partner channel is starving, it usually means the product is being sold but not used. Licenses in a drawer. Pilots that never graduate.

I’ve been saying for a while that agents bolted onto a SaaS platform were going to hit this wall, and I want to walk through why, because the reasoning matters more than the schadenfreude.

The bolt-on problem, specifically

An agent is only as useful as what it’s allowed to touch and what it’s trusted to do. Agentforce, by design, lives inside Salesforce. That’s great if your entire operational reality lives inside Salesforce. Almost nobody’s does. The customer record is in the CRM, sure, but the contract is in a document system, the invoice history is in the ERP, the actual conversation with the client is in email, and the tribal knowledge is in somebody’s head or a shared drive from 2019.

So the “agent” either stays narrow enough to be safe and ends up doing work a workflow rule could have done in 2015, or it reaches outward through connectors and suddenly you’re paying platform prices for integration work while your governance story gets murkier with every hop. Neither version produces the outcome the demo promised. Partners can’t bill against outcomes that don’t materialize.

Then there’s pricing. Agentforce launched with per-conversation pricing, and consumption models like that put the customer in a strange position: the more successful the agent is, the bigger the bill, and the bill is set by the same vendor that controls the platform, the model access, and the switching costs. CFOs noticed. Variable AI bills tied to usage you can’t fully predict are exactly the kind of thing that keeps a pilot a pilot forever. Nobody signs off on production when they can’t forecast the line item.

What actually gets agents into production

Here’s what we’ve learned building AgentWorks deployments, and it’s almost boringly unglamorous.

First, the job comes before the agent. You don’t buy an agent platform and then hunt for use cases. You pick one process with a measurable cost, in hours or dollars or errors, and you build the agent to do that process. Scope is a feature. An agent that does one thing inside hard boundaries ships. An agent that “can do anything across your org” gets stuck in security review, and it should.

Second, governance is designed in, not reviewed in. Every AgentWorks agent runs against defined permissions, logged actions, and a human checkpoint wherever the blast radius justifies one. When compliance asks “what can this thing actually do, and who approved it,” the answer is a document, not a shrug. Your data, your rules. And that has to include the AI working on that data. Your AI, your rules, which means you decide what the agent reads, what it writes, which model it runs on, and where all of it lives. On a platform vendor’s agent, most of those decisions were made for you before you ever logged in.

Third, the economics have to be legible. We do fixed pricing on this work because a client cannot govern what they cannot forecast. If the marginal cost of the agent doing its job is a surprise, the agent will be throttled by the finance department long before it’s throttled by any technical limit.

And fourth, model agnosticism. The right model for a contract-summarization agent and the right model for a triage agent are often different, and both will be different again in eight months. An agent architecture that lets you swap the model without rebuilding the system is worth more than any single model choice you make today. Platform agents lock that decision to the platform’s roadmap.

The honest read on the Register story

None of this means Salesforce built something worthless, and this isn’t a pile-on. It means the “add agents to the platform you already pay for” pitch has a structural flaw: the platform’s interests and the customer’s interests diverge exactly at the points that determine whether an agent earns its keep. Scope, data reach, pricing, and model choice. The partners caught in the middle are just the first ones to feel it, because they’re the only party in the ecosystem paid strictly on real adoption.

The agent era is going to be won by narrow, governed, accountable deployments that a specific team relies on every day. We use ours daily, which is how we know which parts of the pitch survive contact with an actual Tuesday.

If you’ve run an agent pilot this year, on Agentforce or anything else, I’m genuinely curious: what killed it or what saved it? Was it governance, cost, scope creep, or something nobody warned you about? Tell me. The failure stories are teaching us more than the keynotes are.

The post When the partners aren’t getting paid, look harder at the product appeared first on Modular Technology Group.

The Hacker News ran a piece this week on “shady AI”, their sharper name for shadow AI, and called it security’s next big governance problem. They’re right about the diagnosis. I want to push on the cause, because I think most companies are misreading it.

The standard story goes like this: employees discovered that free AI tools make their jobs easier, IT hasn’t sanctioned any of them, so people quietly paste client contracts, patient notes, and source code into whatever chatbot loads fastest. Security finds out months later, usually by accident. Cue the panic memo and the blanket ban.

That story treats shadow AI as a discipline problem. It isn’t a discipline problem. It’s a vacancy.

Nobody owns the question

Walk into a mid-sized firm and ask a simple question: who decides which AI tools are allowed here? Watch what happens. IT says they handle security review but not AI strategy. Legal says they’ll weigh in on contracts when asked. The COO says it’s on the roadmap. Meanwhile a paralegal has a browser extension summarizing privileged email, a sales rep wired a free agent into the CRM with a personal API key, and an analyst is running quarterly numbers through a consumer chatbot that trains on inputs by default.

None of those people are being reckless in their own minds. They’re being productive. The tool worked, nobody said no, and more to the point, nobody was there to say no. Or yes. The chair where that decision should get made is empty at most organizations, and shadow AI is simply what fills a vacuum.

Bans don’t fix vacuums. A ban is a “no” issued by someone who wasn’t in the room when the work needed doing, and employees treat it accordingly. The Hacker News piece touches on this: prohibition pushes usage underground, off the corporate network, onto personal devices, where security has zero visibility instead of partial visibility. You traded a manageable problem for an invisible one and called it policy.

What actually fills the chair

This is the exact gap the fractional Chief AI Officer exists to close. Not a consultant who writes a 40-page acceptable-use policy and leaves. Someone who sits in the seat, part-time but genuinely accountable, and does four unglamorous things.

First, inventory. You can’t govern what you can’t see. Before any policy discussion, find out what’s actually in use: the browser extensions, the personal subscriptions, the API keys nobody logged. Most firms are shocked by this list. The shock is useful. It converts an abstract worry into a spreadsheet with names on it.

Second, sanctioned alternatives. Here’s the part the ban-first crowd skips. People adopted these tools because the tools work. If you take away the free chatbot without replacing the capability, they’ll find another free chatbot. The answer is a private AI workspace they can actually use, running on infrastructure you control, where the drafting and the summarizing and the analysis happen without the data ever leaving your jurisdiction. At Modular that’s not theoretical. Our own teams run daily on the same private stack we deploy for clients, hosted on US soil, at a fixed monthly price, so the finance conversation is as boring as the compliance conversation. Boring is the goal.

Third, a real AI Program Office. Small, standing, cross-functional. It reviews new tool requests in days instead of quarters, keeps the approved list current, and gives employees a place to ask “can I use this?” and get an answer before they’ve already used it. Speed matters more than people admit. An approval process that takes six weeks is a prohibition wearing a lanyard.

Fourth, policy that says yes with conditions. “AI is banned” and “AI is fine, go nuts” are equally lazy. The workable version reads more like: this class of data can go into these tools, this class cannot, here’s the sanctioned path for the gray areas, and here’s who to ask when you’re not sure. Employees follow rules they can actually follow.

The sovereignty thread underneath

There’s a reason this maps so cleanly onto how we think about infrastructure. Your data, your rules. That’s been the thesis all along, and shadow AI is what it looks like when the rules never got written. Every unsanctioned tool is a small, silent transfer of control: your client’s contract now lives in someone else’s training pipeline, under someone else’s terms of service, in someone else’s jurisdiction. And that includes the AI working on the data, not just the data itself. Your AI, your rules. Governance without agency over the models and the tooling is just paperwork about someone else’s decisions.

The firms that get ahead of this won’t be the ones with the strictest bans or the longest policies. They’ll be the ones where somebody actually owns the question, where the sanctioned path is easier than the shadow path, and where “which AI touched this data” has an answer you could give a regulator without sweating.

The empty chair is the whole problem. Filling it doesn’t require a full-time executive salary. It requires deciding that the question deserves an owner.

Here’s what I’d genuinely like to know from the people reading this: when you last found an unsanctioned AI tool inside your organization, how did you find it? An audit, an incident, or dumb luck? The answers to that question tell you more about your governance posture than any policy document will.

The post Shady AI is what an empty chair looks like from the outside appeared first on Modular Technology Group.

The post DBS gave 1,500 employees AI agents. The interesting part is what had to exist first appeared first on Modular Technology Group.