From Seeds to Candidates

Looking at Michelangelo's plan for the Sistine Chapel, I imagine him alone with the scale of the work ahead of him, deciding that he will finish it alone.

In that imagined scene, the ambition comes with a decision to exclude others. The whole project stays in one person's hands. I call this the Michelangelo temptation.

I think every senior developer can feel that temptation today. You have the experience, you can see the architecture, and AI gives you the capacity to carry much more of the execution yourself. Work that used to require a team starts to look possible alone. Involving others can begin to feel like something that slows you down.

That is a powerful temptation. It also leaves everyone else's ability to build dependent on you.

I think we have found another path at DashQ. A path that can make anyone a Michelangelo: give people the means to carry their own vision much further, with the knowledge and contribution of others still part of the work.

In the previous article, I described the seed: a first artifact that people and AI could bring into a shared conversation to clarify what should be built. That shared conversation was already a step down this other path. The artifact people bring is now much more advanced, and the intelligence helping them build it stays with the work.

We have moved from seeds to candidates.

The agent is still there when we come back

Part of this change comes from agents that are always on, with persistent memory. They can keep an objective across conversations, continue working, and come back with a result or a question.

We have been giving these computational entities an identity and wide access to the systems we use in the company: email, ticket tracking, shared drives, reporting, code, testing, and live monitoring. They can also prepare videos to showcase the software and explain what has been done.

The connections between these systems make a large difference. A problem starts in a conversation. The explanation may be in a document, the implementation in a repository, and the evidence in a report. If the person has to carry everything between those places, their availability still determines how far the agent can go.

With access and continuity, the agent can follow the work through those places. It can investigate, build, test, and prepare something we can inspect when we return.

For both company assistance and software production, we have reached the point of AI working 24/7. There are still decisions that need us. But ending a conversation no longer has to end the work.

We bring these capacities together through Dashnet, our central intelligence. This also gives us a continuing responsibility: keeping the context current. An agent that remembers yesterday's decision needs to learn when we change it today.

The point where we want it to stop

Wide access makes the next question very concrete. Where do we want the agent to stop and bring us back into the work?

Email is a good example. An agent can find the relevant conversation, understand the issue, and prepare a reply. The next click can create a commitment for the company or expose information to the wrong person. A mistake there can be catastrophic for a business.

This is where we deliberately keep friction.

I distinguish friction from guardrails. A guardrail defines a boundary the agent cannot cross. Friction creates a point where the work comes back to a person: here is the action, here is what it will affect, and here is the decision needed to continue.

I think it is time to start moving some AI activities from guardrails to friction, as we do with trusted members of a team. We give them more responsibility as we learn what we can rely on, while keeping the important decisions explicit.

Trust has a scope. We can trust an agent to investigate and prepare a customer response while retaining approval over sending it. Access to another customer's data remains a hard boundary. These are different decisions about the same agent.

The difficult work is placing the friction well. Too early, and the person has to help produce the result. Too late, and the consequence has already happened. I want the agent to bring us something concrete at the point where our judgment matters.

Within the agent's permitted scope

1. PrepareRead, connect, draft
2. Bring us backReview the actual message
3. SendAfter authorisation

Anyone who wants to can become a builder

This is where the other path becomes concrete. Take a colleague who wants to improve a reporting workflow. With AI, that person can develop the idea into working screens, connect behavior, try alternatives, and prepare a demonstration. The discussion can begin with something we can use.

This changes who gets to build. Someone with a deep understanding of the problem can carry the work much further before asking a technical team to take it over.

A candidate is an advanced artifact that has not yet passed our production standards.

The word matters. It recognises that substantial work has been done, while leaving the production decision open. A useful demonstration may still depend on the wrong data, miss an access rule, or behave badly when another service fails.

The person who understands the business problem can challenge the behavior. The engineers can challenge the foundation. The agent can keep working on both. Clarification, implementation, and review become connected conversations around the same candidate.

That is the part a simple production line misses. The candidate can change our understanding of the request. A test can reveal a missing business decision. A review can send us back to the person who knows why the workflow exists. We need the memory of those decisions to travel with the work.

Terraforming the infrastructure

As more people become builders, the technical team's work becomes more concentrated in the last lines of defence and in terraforming the infrastructure to support the growth.

There is a temptation to see this as less technical work. I find it highly demanding. The questions we are left with often sit at the core of technology: who owns the data, how services agree on a state, where a permission is enforced, and what happens when an operation only partly succeeds.

One candidate can hide a weak foundation. Many candidates arriving together will expose it.

We need environments in which agents can work without colliding, a reliable path from development to production, and enough visibility to understand what changed. When something goes wrong, we need to recover the system and improve the conditions for the next run.

This is where I want our technical attention to go: the critical decisions, made consciously and tracked. A decision about ownership should not have to be rediscovered by every agent. A recurring failure should become an improvement to the factory.

This gives senior developers another place to put their experience. We can prepare the ground on which many people build, and make the difficult decisions that allow their work to hold together. Our technical depth becomes a way to expand who can create.

An assistant needs to know who is who

This is also why we are preparing for the new generation of personal assistants. We are testing Meta's Muse and OpenAI's Dots, first to understand how to use them internally, then to make DashQ easier for them to use on behalf of their users.

Muse and Dots both describe assistance that continues between conversations and retains context over time. Their usefulness inside a company will also depend on understanding the people around the work.

In the reporting example, the assistant needs to know who understands the metric, who owns the data, and who can approve the change. An organisation chart answers only part of that.

We have started building this understanding in Dashnet: roles, relationships, expertise, and responsibilities. The directory gives us a starting point. Knowledge added through conversations needs confirmation from the relevant person and a way to change when their responsibilities change.

On the product side, our API and MCP work aims to make the same business capabilities available to applications and agents, with the same permissions and approval requirements. The actual experience still has to be tested with the assistants we use.

We are making more of the company understandable and actionable for these entities. As that happens, a person can start something much more ambitious and stay responsible for it without performing every step.

That is the path I mean when I say anyone can become a Michelangelo. The ambition can belong to anyone. Building the conditions for it remains a collective effort.

The next challenge is to keep the whole organisation aligned while all of this work continues.

Continue to Part 6: The Factory as a Living Contract

Cover: Michelangelo, Scheme for the Decoration of the Ceiling of the Sistine Chapel, ca. 1508, Detroit Institute of Arts, 27.2.A. Cropped detail; public-domain reproduction via Wikimedia Commons. The solitary artist in the opening is my metaphor, not a scene depicted in the drawing.