All field notes

An MCP gateway is where an enterprise turns a protocol into a control. This playbook builds one: identity for agents, delegated user context, per-tool authorization and gates, rate limits, logging, and the registry that makes servers an inventory.

Giving an agent a database connection is the fastest way to get value and the fastest way to get a breach. This playbook builds a Postgres MCP server that exposes safe, permissioned tools instead of raw SQL, with the controls that make it production-grade.

Salesforce is the system agents most often need and the one where a careless integration does the most damage. This playbook builds a thin, permissioned MCP server over the Salesforce API, from tool design to production.

ServiceNow holds the tickets, the CMDB, and the approvals that ITSM agents depend on. This playbook builds a thin, permissioned MCP server over the ServiceNow APIs so agents extend the platform instead of bypassing it.

The first Digital FTE decides whether there is a second. This decision guide shows how to pick a workflow that will earn its place, what has to be in place before you start, and the sequence that gets it to accountable operation.

MCP makes it easy for agents to reach your systems, which is exactly why its deployments need discipline. This guide covers the risks that recur in reviews, over-privileged servers, injection through tool results, unvetted servers, credential leakage, and the controls that address each.

An MCP server can be a two-day wrapper or a real engineering project. The difference is the underlying system, the number and kind of tools, authentication, and how much testing consequential actions demand. This guide sets out the drivers and effort profiles.

Every agent needs to reach your systems. You can wire each one directly to your APIs or expose the systems once through Model Context Protocol. This comparison explains the trade-offs and when each approach is right.

Two neighbouring markets with similar cost bases. The differences are in engineering depth, seniority supply, and sector maturity.

Both countries have the engineers. The decision turns on scale, seniority per dollar, and which firm you can actually get attention from.

The Philippines leads in spoken English and operations; Pakistan in engineering depth. Choosing depends on which you are actually buying.

Vietnam's engineering reputation is well earned. The practical difference for most buyers is English and which markets each overlaps with.

An agentic enterprise is a company where AI agents do a substantial share of defined work under human accountability, on a shared platform, with governance and measurement built in. This essay describes what that looks like in practice, how it differs from a company that has merely adopted AI tools, the operating model that makes it work, the risks that come with it, and the sequence for getting there without losing control.

Hundreds of AI tools launched; most were thin layers over a model API. Consolidation is under way, and what survives has either real infrastructure or real domain depth.

The token bill is the cost everyone sees. Evaluation, human review, monitoring, and data maintenance usually cost more, and they are the lines missing from most business cases.

Prompts determine system behaviour, which makes them code. The practices catching up — version control, review, testing, ownership — are the ones every other config went through.

Most production tasks are narrow. Small models fine-tuned for them are faster, cheaper, and more predictable than frontier models, which is why they keep appearing in real systems.

Board conversations about AI are shifting from opportunity to accountability. The questions are specific, the answers require records, and most organisations cannot produce them.

Adding AI to an existing product is faster and produces a feature. Designing around what the model makes possible produces a different product, and the gap widens over time.

A policy saying humans review AI output produces rubber-stamping unless the interface, the workload, and the incentives support genuine review. Oversight is designed, not declared.

AI coding agents produce more code faster, which makes software quality a throughput problem for verification rather than a throughput problem for writing. This essay explains what changes when machines write code, why specifications and tests become the scarce input, how review must adapt, and what engineering leaders should change now to keep quality rising while output grows.

Banking is a data and process business under heavy regulation, which makes it both an ideal candidate for AI and one of the hardest places to deploy it. This essay looks at what changes in operations, risk, servicing, and product over the next five years, what moves to AI first, what stays human by design and by law, and how bank leaders should prepare without betting the franchise on unproven systems.

Consulting sells judgment delivered through people and documents, and AI automates much of the research, analysis, and document production that filled billable hours. This essay looks at what changes for consulting firms over the next five years, why the business model shifts from hours to outcomes and from slides to systems, what stays human, and how firms and their clients should prepare.

Customer support was the first function to adopt AI at scale and the first to learn that deflection is not resolution. This essay looks at what changes over the next five years as AI agents move from answering questions to resolving issues, how team structures and metrics change, what stays human, and how support leaders should prepare without repeating the chatbot mistakes of the last decade.