Opening a system of record is not one decision. It is five.

People cannot specify the tool they have never held. Ask a leadership team which agents they want and you get a list of what they already do, slightly faster. Give them two working ones and the requests change completely within a fortnight. This rung exists to change what the organization can imagine, and it is the rung where IT carries no new risk at all.

Speed of learning. The number of people who form a daily habit.

One real one: people paste confidential material into consumer accounts, and enterprise accounts before anything else closes it. The other risk is treating this rung as the destination, running a successful pilot and stopping. That is the common failure and it looks like success for about a quarter.

Skills defined as instructions plus reference files, held in the user's own workspace. The person uploads what the work needs. No connection to any system.

Two or three uses are in genuine daily use by people who are not enthusiasts, and the requests coming back are for the tool to see something it cannot currently see.

The first thing every one of those requests asks for is context the person already has: the thread, the calendar, last quarter's deck. This is the cheapest capability increase available, and it runs entirely inside collaboration tooling you already govern.

Removing the copy and paste. The tool stops being a place you visit and becomes part of the working day.

Access is granted per person and inherits that person's permissions, so an over-permissioned employee becomes an over-permissioned agent. That is an existing access-governance problem AI makes visible rather than a new one, and it is worth resolving on its own terms. Expect central IT policy to be the blocker rather than technology.

Connectors to mail, calendar and the document store, scoped read only, under the individual's existing rights. Shared assets many skills draw on, such as the presentation template and brand basics, are installed at tenant level rather than carried around by each person.

People start asking questions whose answer lives in the CRM or the ERP.

Everything up to here improves how an individual works. Reading the systems of record is where the conversation moves to the business, and it is the first rung where IT does substantial work. It is also, in practice, the rung that resolves the write debate, because it is where you find out what your data is actually like.

Learning two things at once: whether agents grounded in real data produce materially better judgment, and whether the data can support it. The second answer is frequently no at first, and finding that out on a copy costs nothing.

Going to production. A jump host, a security review and a queue, and a month before anyone learns anything. Dumping the schema. Hundreds of tables produce an agent that retrieves confidently and wrongly. Silent staleness. An agent reading partial data answers anyway, so coverage has to be stated rather than assumed.

A curated export from the warehouse into a separate store, joined into a shape an agent can use, with a protocol layer over it. The legacy system is not touched and not replaced. It gains an interface.

Bring in the data owner and process owner now, while the request is only to read. They are the people whose agreement rung four will require, and they will have spent a rung watching it work before anyone asks them for it.

Grounded answers are demonstrably better than ungrounded ones, the data gaps are documented, and the system owner has seen enough to have an opinion about writing.

The objection to write access is that AI will degrade the data. It is a reasonable fear, it is pointed at broad write permission, which nobody should grant, and it is not an argument against writing. Look at what the free-text fields in a mature CRM contain today. One person writes three words. Another writes everything that was said. Most write nothing, because the meeting is over and the next one starts in five minutes.

Getting knowledge out of individual inboxes and into shared systems. A meeting outcome sitting in one person's mail is invisible to the company. The same outcome on the customer record is available to everyone who touches that account next.

Broad write scopes, obviously. Less obviously, writes that no human ever reads back, which is how a small systematic error becomes ten thousand records. And accountability going vague at exactly the moment it starts to matter.

Constrain the surface. A gateway exposes one operation, not the API. Create an activity. Nothing else. Constrain the shape. The agent writes a defined structure rather than free prose, in a field the system already has. Keep a person in the loop, at first. Every write is proposed and approved until the approvals stop changing anything.

The write path has run under human approval long enough to have a boring error rate, and the system owner will say so in writing.

No new permission is granted here. Something built by one team turns out to be wanted in six countries, and without somewhere to put it you get one of two bad outcomes: everyone rebuilds it slightly differently, or a central team becomes a queue.

Reuse without a bottleneck, and consistency in what agents say about the company.

The first attempt is almost always a page of downloadable files with no version control behind it. It works for a month, then nobody knows which copy is current. The quieter risk: handing someone a skill is not the same as them using it, and a library measured on installs rather than use will look healthy while nothing changes.

A curated library people install from, filtered by role, with an owner, a version history and a published quality bar. And a company context layer every skill draws on: who we are, the competitive picture, how we write, the current template. Distribution carries the training with it.

Ownership has moved. A presentation skill used in four countries belongs to whoever owns the brand, because when the template changes the skill must change with it.