Re-Use and Enhance

Automation gets quoted as though every job starts on a blank page, and that assumption is where the budget goes. Analytics reporting, DNS authority, publishing and metadata, repository chores and application mail exist here as executed procedures with their traps recorded as rules. A first project mostly installs proven work.

What is genuinely bespoke is the system nobody outside the company runs: the scheduling database, the invoicing system, the supplier portal. Each gets a wrapper; permissions, consent and quota arithmetic are known work. Microsoft 365 is reached through the same layer, and Claude Cowork works across the whole set.

The commercial effect is quiet, because the licence count does not move. What changes is what those systems do together: a question spanning three of them stops requiring somebody to open all three, and the afternoon that used to go into the crossing comes back.

A Skill Covers What the Demo Skips

A recipe that only describes the happy path is why the second person gives up. The skill carries a troubleshooting table with the fix beside each symptom: a server that never appears in the tool list, credentials minted with the wrong scope, a refresh token expiring after seven days while consent is in testing mode, an account with no access to the property.

It also covers the work either side. Measurement means the account, the property, the web stream, a snippet on a site gating analytics behind cookie consent, and the privacy-notice obligation that arrives with tagging.

On the publishing side, an API project that has not passed its compliance audit forces every upload private regardless of what the request asked for, and chapters parsed from description timestamps rather than an API field fail to render unless the format is exact.

Systems Answer on the Device the Team Uses

Every system wrapped as an MCP server answers through one interface: the chat client the team already uses. That interface runs on whatever the person has in hand. A question about this week’s invoices, tomorrow’s schedule, or a client’s balance does not wait for a desk with three applications open.

The scheduling database, the bookkeeping API and the supplier portal each expose their own interface; the MCP layer gives the agent one typed way in. The same connection that works at the office also works from a phone in transit, because the work happens in the chat window, not in any installed application.

Writes wait on a person: the model produces a draft, and a form rendered in the chat client performs the only write, reviewed on screen before anything is saved. The question that used to queue until someone was back at a desk gets asked and answered the moment it comes up.

10
ordered reference leaves behind one executed DNS method
Mock first
connector code running against a stub until the key lands
Zero
credential values in a procedure file, only the file name
Read-only
reporting servers that report, stated inside the skill

Every System in the House Gets Reached, Nothing Gets Replaced

Reach What Is Already There 3 steps
01

Wrapped in Front, Not Rebuilt Underneath

The fear that stops most connector projects is that something will have to be replaced first. Nothing is replaced. The scheduling app, the bookkeeping system, a supplier portal, a ticket system or an app with a web interface and no documentation is each wrapped as an MCP server, sitting in front of the system that already runs. The system keeps its own users, its own database and its own interface.
02

The Planner Database and the Bookkeeping API, Reached as Tools

The systems holding the actual work are usually the ones with no connector on any shelf: a scheduling database built in-house, an industry package nobody outside the trade runs, a bookkeeping API with its own login. Each gets a wrapper over the interface it already exposes, so vouchers, tax figures, contacts and schedules are asked for in the office's own vocabulary. Microsoft 365 is reached through Graph and belongs to the Cowork page.
03

Reporting Answered in a Conversation, Not a Dashboard Session

Reporting questions die in the gap between somebody having the question and somebody having time to open the dashboard. An analytics MCP server closes it: a dedicated cloud project, the Admin and Data APIs enabled, an OAuth client, and a server entry in the tool configuration. After that, users yesterday, top pages, funnel and realtime numbers are answered in a normal conversation. Reporting only, which the skill states plainly.
Handed Over as Readable Text 3 steps
04

What Actually Ships Is a Skill Plus a Connector

An automation that exists only as a script on somebody's laptop cannot be reviewed, handed over or repeated by anyone else. What ships instead is a pair: an MCP server giving the agent a typed way into the system, and a written skill saying when and in what order to use it. The anatomy of that file belongs to the Cowork page. Here it matters because a connector without a recipe gets used once and then guessed at.
05

The Failure Modes Become Rules Nobody Rediscovers

Expensive failures are the silent ones, and they repeat because nobody wrote them down. Two of them now live as rules inside their skills. Any property omitted from a video update is deleted, so an update always sends the full snippet, and an existing video id can never accept a new file, which makes a re-render a fresh upload. Neither is in the vendor documentation, and both cost an afternoon once before becoming a line in a file.
06

Built and Tested Before a Single Credential Exists

Integration work usually stalls waiting for a credential somebody else has to issue, and the waiting is where budgets go. Mock mode removes the dependency. It is on by default, credentials sit behind one configuration section, and a status endpoint reports which keys are missing by name and never their values. The whole publishing feature is built, tested and reviewed first, then the same code path runs live once the key lands.
Guardrails on Every Write 2 steps
07

Writes Stay Behind a Confirmed Action

An agent holding write access to a live business system is the part that rightly makes an owner nervous. It is therefore never given one. The model is restricted to producing a draft, and a form rendered in the chat client performs the only write. A month of scheduling imported from a spreadsheet is proposed in full, grouped by location with real driving times, and reviewed on screen before a single record is saved.
08

No Credential Value Ever Enters a Procedure File

Credentials leak through the files nobody classifies as sensitive: the runbook, the procedure, the committed configuration template. No skill file holds a value; it names the git-ignored file that holds it. A model registry returns keys never in plain text, a committed template ships blank with real values in user secrets or environment variables, and the endpoint itself is protected by OAuth with Microsoft Entra ID.
Where the Second One Gets Cheap 2 steps
09

What Cannot Be Automated Is Named First

A connector list that promises everything is the reason nobody believes any of it, so what is out of scope goes first. A reporting integration stays read-only, and changing analytics configuration still happens in that product's own interface. Metadata, chapters, captions, thumbnails and the upload itself are API work, while cutting, blurring and end screens exist only in the video editor and cannot be automated at all.
10

The First Connector Is Expensive, the Fifth Is a Config File

The first connector costs more than expected, which is why the fourth never gets built. Moving a domain's DNS authority took a week of investigation the first time. It is now ten ordered reference leaves covering inventory, apex design, zone authoring, mail carryover, cutover and a stale-record audit, derived by executing it live and re-run on two further domains since without repeating any of the investigation.

Frequently Asked Questions

Does anything we already run have to go before this works?
No. A connector is a layer sitting in front of a system, speaking to the interface that system already exposes, so the people who use it keep their logins, their screens and their working habits untouched. Adding one changes neither how the system is licensed nor who administers it, and the vendor relationship behind it stays out of the conversation. The honest test is removal: switch the connector off and every system carries on exactly as before.
Where does the money actually go once the connectors are live?
Three measurable lines, and none of them is a surprise. Model usage is captured per call as structured logs, so spend per run is inspectable after the fact rather than estimated. Hosting is containers on a box already paid for monthly. API quotas are arithmetic, not guesswork: a publishing API allows 10,000 units a day with an upload costing 1,600, so the ceiling is known before anything is built rather than discovered at it.
Does connecting these systems copy our data anywhere?
The business data stays in the systems that already hold it, because nothing is copied into a new platform to make a connector work. The integration layer runs as containers on a box under our own operation rather than on a vendor platform, and it keeps no store of its own to fall out of step. Microsoft 365 content stays in your tenant. Where the hosting concept has to be EU-hosted, the compliance pass settles that per service before anything is connected.
What happens when the person who set it up is not available?
Availability was never the dependency here. Every automation is checked into the repository next to the system it operates, so it is found where the work happens rather than in somebody's private notes, and it is versioned, so what changed and who changed it is visible. Credentials never sit inside it, only the name of the git-ignored file that holds them. A colleague, or a fresh agent session, runs the identical steps and gets the identical result.