Agentic Development, Part 7 · 25. October 2026
Connecting the AI Organisation
In my July talk, I described AI working as members of an organisation. Each would have its own identity, assigned work, and permissions. People would check the results, step in when needed, and gradually delegate more.
We have been building that organisation throughout this series. Our software factory builds and tests applications. In shared conversations, people and AI work out what to build and review prototypes together.
Personal assistants now help each person take part in that work. They follow projects, identify what needs attention, and take on tasks for their user.
Our objective is to hand over more work to AI, including following up with people and keeping them informed. We need to stay clear about what we want done, who is doing it, and who can make the decisions.
Give each participant a place
Claude works as a teammate. It joins team conversations, builds prototypes, and helps coordinate projects. It has its own accounts and permissions for email, ticketing, and GitHub. Different people can ask it for help.
A Dot supports one person. It learns about their work and preferences, reads the conversations and applications they connect, and helps them get things done. It can investigate a problem, propose a next step, or carry out a task.
Dashnet gives these assistants company knowledge and the data they are allowed to use. The software factory builds and tests the changes the team agrees to make.
We are building similar roles into our client products. VLA works alongside leasing teams. The DashQ Analytics Assistant helps clients understand their data. We use OpenMuse to build personal assistants for residents and professional users of the DashQ mobile app.
The client work came from sales initiatives, while internal Dots adoption came from team feedback. The two developed in parallel. With OpenMuse, we can design the experience ourselves and control which applications and actions the assistant can use.
Both need reliable information, clear permissions, access to applications, and a way to check results. The factory builds and improves the software they use.
Prepare a decision from scattered information
My Dot recently brought a meeting conflict to my attention on its own. It had been following my work in the background, including the project coordination Claude maintained in Slack, and identified a problem with my travel schedule.
Dot connected three things: the decisions expected at the steering committee, the meeting in my calendar, and my flight itinerary. The steering was at 13:00 Toronto time; my arrival was at 15:20. I would be in the air when the team needed my participation.
It suggested asking someone to lead the meeting in my place or finding another time, and listed the decisions that needed preparation. I needed to attend and wanted to speak with a colleague first. The meeting stayed unchanged.
Dot had gathered the information I needed to decide. Earlier in that conversation, Dot had flagged a client issue from email. I explained that someone else owned it; Slack showed that the colleague had already replied. It corrected its answer. An issue can matter to me without being mine to handle.
We also see Dots reading Slack in the background and alerting users when someone needs data access or a missed deadline will delay other work. They can investigate before asking the person to step in.
Identity follows the work
In the steering example, Dot could investigate the conflict while leaving the meeting unchanged. Moving it would mean acting through my calendar account and changing a commitment with other people. That is where identity becomes a practical question: whose account is the assistant using, and what is it allowed to do?
The person asking for work and the account carrying it out are not always the same. A teammate can receive my request and act through its own account. A personal assistant can use an application connection I have authorised. The application needs to know which account is acting.
Claude and VLA have their own identities. A request from a person does not automatically transfer that person's permissions. More recently, Claude can also ask to use the requester's identity. The application must distinguish that from Claude acting through its own account. For a Dot, the same question applies to each connected application: which identity does that connection use, and which actions does it permit?
Agents also need a way to use our applications. I prefer an MCP connection when available, then an API: both let the agent call application functions directly. Otherwise, it can use the screen, much as a person would.
The promise is that an agent could do the computer work of a remote employee, even in applications we have not connected directly. It still needs an account with permission to do the job.
Carry out the work inside an application
Early users already ask Dot to change client settings in our main application. The employee decides what should change. Dot can find the settings, fill in the form, and save the update.
The employee specifies the client and the setting to change. Dot uses the connected account to find the right screen and prepare the update. It can carry out work already delegated to it, asking for confirmation when the person or the application requires it.
After making the change, Dot needs to check the saved setting in the right client account and tell the employee what happened. If the result is uncertain, it should check before repeating the operation. The delegated task includes that follow-through.
From a recurring task to a product improvement
Imagine a colleague preparing a monthly client report. Each month, they copy figures into a spreadsheet, compare them with the previous month, and explain the changes. Their Dot helps with the preparation and suggests making that comparison available directly in the reporting application.
The colleague adds what the assistant cannot decide alone: which figures matter to this client, what deserves an explanation, and how the comparison should look.
With the colleague's agreement, Dot brings the proposal into the team channel. Claude builds a prototype so people can react to an actual report. They review it in the same conversation and refine it together. This is the pairbuilding process from Part 4.
The technical lead also reviews the prototype: are the figures coming from the right sources, and does the change fit the existing application? Their own Dot can flag the review and gather the information they need. The lead can then approve the work for the factory.
The factory builds the feature, runs automated tests, and asks the team to try the report. It fixes the problems they find. After testing and approval, it releases the change and checks that it works in the live application.
The colleague is notified when the feature is available. Their Dot can use the new comparison for the next report, saving them the repeated spreadsheet work.
The colleague did not have to follow every development step. They explained what they needed and reviewed the result. Other people made the decisions that belonged to them. The agents kept the work moving between those moments.
Delegation grows through use
Our first group included six people in six different roles. From the first day, they used Dots extensively to change client configurations, handle handed-off lead conversations, reschedule meetings, and review financial reports before sending them to clients.
They continue to use them more and connect more applications. From my observation, this is the fastest internal adoption since we started building our data and AI capacities.
Knowing the company helps Dot understand the work. Access to applications lets it fill in forms and handle administrative tasks. It can also notice a problem and offer help without waiting to be asked.
Each person learns what they can trust their assistant to do. They check results, correct misunderstandings, and give it more responsibility. For some tasks, that includes communicating with others. For others, they still want to approve the result. We already work this way when delegating to colleagues.
There are still practical limits. Users sometimes need a quick answer while their Dot is occupied with background tasks. We need better ways to interrupt that work or change its priority. Critical actions such as payments can still require platform approval even when a user wants to delegate them fully.
In July, I described people managing AI workers that keep working and ask for help when they need it. We are building the accounts, permissions, knowledge, and tools that make it possible to give them more of that work.