Every AI agent pitch comes with a promise. Cloud vendors promise elastic scale and frontier models. Terminal-based “local” agents promise your sensitive work never leaves the building. Then someone looks at the network traffic and finds that the “local” agent has been shipping your schemas, code and query results to a cloud-hosted model the whole time. Meanwhile, the cloud agent everyone was afraid of turns out to be easier to lock down than the developer laptop it was supposed to replace. In this week’s newsletter, we investigate what each runtime actually exposes, and why the debate itself misses the point. Most of what gets said about cloud and local agents is either overstated or outright wrong. Where your agent runs matters far less than what sits underneath it: the data foundation it reasons over, the identity it acts under, and whether you can trace every tool call it makes. Here are 3 things the marketing won’t tell you: - ☁️ What really leaves the building in the cloud: Learn why the tools a cloud agent calls usually run inside your own environment, and why the real exposure is the context you send out. You’ll also see how least-privilege agent identities, private connectivity like AWS PrivateLink or GCP Private Service Connect, and MCP gateways with allowlists and kill switches keep that flow contained. - 💻 Why “local” isn’t airtight: Discover why many terminal agents run their harness on your machine but send their context to a cloud model. Even fully local models don’t make the attack surface disappear. It moves to shell access, prompt injection hidden in files, and credentials sitting on developer workstations. - 🧭 Per-workload routing decisions: See why the answer isn’t picking a side. It’s deciding, workload by workload, which data may cross which boundary, under which identity, and with what evidence left behind. It also points to two resources that go deeper on the foundations underneath: Ignition’s article on why your data architecture is holding your AI back, and the Scalefree expert sessions on getting your data platform ready for agentic AI and orchestrating agentic workflows.

Every MCP integration works in the demo. The trouble starts the day an agent reads something it shouldn’t trust. A resume arrives with a hidden instruction buried in the text, the agent dutifully reaches for its database tool, and the only thing standing between your salary table and an external endpoint is a long-lived API key with admin rights that nobody remembers issuing. In this week’s newsletter, we cover the half of MCP adoption the launch posts skip. The Model Context Protocol killed the N × M connector nightmare, but its authorization framework is optional, and nothing in the protocol forces you to switch it on, scope it tightly or put a policy check in front of a tool. That gap is not a model failure. It is an architecture one, and it is exactly where agentic pilots quietly turn into incident reports. Here are 3 guardrails that close it: - 🔑 Delegated OAuth, done right: Learn why static keys should be retired on remote MCP servers, and why “just forward the user’s token” is the one shortcut the spec explicitly forbids. You’ll also see how token exchange gives every downstream call its own user-scoped credential. - ⚖️ A policy-as-code gateway: Discover how a Policy Decision Point running AWS Cedar or OPA checks every JSON-RPC request against hard constraints before a tool ever executes. It also explains why Cedar’s formally verified semantics and microsecond evaluation make that check effectively free. - 🚧 Egress, approvals and audit: See why identity alone won’t stop a prompt injection, and how locking down outbound tools, gating high-impact actions behind a human, and logging every tool call as a privileged event turn a breach into a blocked request. It closes with a practical checklist for data and security engineers. It also points to two resources that go deeper on the foundations underneath: the Scalefree expert session on getting your data platform ready for agentic AI, and Ignition’s article on why your AI is only as trustworthy as your data.

Ask three systems how many active customers you have and you get three answers: 5,892 from the Sales CRM, 6,155 from the Marketing DB, 6,001 from the Finance Ledger. Sales counts recent logins. Finance counts accounts with an open balance. The old warehouse relies on status flags nobody has updated in years. Then you put an AI agent on top, and it blends the rules or quietly picks one at random. The failure doesn't look like a failure: a clean chart, a plausible number, a green "task completed," and no warning that the number is wrong. In this edition of datapro.news, we look at why the gap between AI demos and AI you can trust is a semantic problem, not a model problem. Gartner's numbers set the stakes: 60% of AI projects without AI-ready data are expected to be abandoned, and 63% of organisations either lack the right data management practices for AI or aren't sure they have them. The model can be as capable as you like. If business meaning was never written down, it is guessing. Here are the 3 layers the fix actually comes down to: 🧭 The decoder ring. Learn the difference between the three layers of meaning that most teams blur together: a taxonomy gives you the vocabulary (what a SKU is), an ontology gives you the concepts and how they link (what an Order is and what it connects to), and a semantic layer gives you the rules (what "Active" means, and who decided). The evidence is striking. In published benchmark work, GPT-4's accuracy on enterprise questions rose from 16% against a raw schema to 54% when given an ontology. It's the same model with the same data, and the only change is that the meaning was made explicit. The semantic layer is also where enterprises most often stall, because that is where conflicting source definitions finally have to be reconciled. 🏛️ The Data Vault backbone. See why Data Vault is a natural home for business meaning, because its structure echoes an ontology. Hubs hold the core concepts' business keys, Links record the relationships, and Satellites carry the descriptive detail. The Raw Vault stores data exactly as sources deliver it, so every disagreement stays traceable. The Business Vault then resolves the conflict with one agreed rule, instead of leaving it to whichever dashboard or agent happens to run the query.

I am here to grow together. Here are the details on how we grow through collaboration.

Every evaluation-driven development pitch lands the same way: write the eval first, the way TDD writes the test first, and let the score gate the release. The suite genuinely is better than the demo and the product manager's intuition it replaced. The trouble starts about two weeks after adoption, when someone asks whether a passing build means anything a user would recognise as quality — and the answer turns out to be that nobody knows, because the judge producing the number was never scored against a human. In this edition of datapro.news, we cover the step the announcements skipped. EDD has a real academic anchor: CSIRO's Data61, with UNSW and ANU, published the reference treatment in November 2024 and revised it as recently as November 2025, and its EDDOps model treats evaluation as continuous governance rather than a terminal checkpoint. Read the definition carefully, though. Evaluation there is an umbrella covering testing, benchmarking, validation, monitoring and risk assessment — it is a process model, not a metric. It tells you where evaluation belongs, not what good is. The load-bearing component in "the evals passed" is a judge nobody has graded. Here are the 3 layers the decision actually comes down to: 🔬 Error analysis: Learn why the industrial methodology inverts the order most teams use — read real traces, open-code the failures by hand, cluster into a taxonomy, count frequencies, and only then build evaluators. Plus the UIST 2024 finding on criteria drift that quietly kills the clean TDD analogy, since grading outputs is how people discover their criteria, and the two contrarian positions held by the practitioners with the most reps. ⚖️ LLM-as-a-judge: Discover the fair version of the problem rather than either caricature — over 80% agreement with humans in the foundational MT-Bench work, matching human-human levels, alongside documented position, verbosity and self-enhancement bias. The most careful position-bias study ran 15 judges across 22 tasks and 150,000-plus evaluation instances, and found the bias worsens as the quality gap between candidates narrows, which is exactly where your regression tests live.