This isn’t just buzzwords. The speakers at the seminar and my own experiences show that the change touches the entire value chain: roles, team sizes, processes, and the way the business participates in development.
Roles are converging and teams are getting smaller
Agent-based development changes team dynamics in a fundamental way:
- Roles are converging. The roles of project manager, product owner, and architect converge in the first phase. Everyone participates in definition and validation.
- Team size is shrinking. Teams of 2–3 people work, because the communication overhead of a larger team is too slow for agent-assisted development.
- Scrum rituals don’t scale. Development iterations are too fast for traditional sprint cycles. Code needs to move faster than two-week sprints allow.
- The development step is only a small part of the value chain. Business decisions are made thoughtfully, and customer feedback doesn’t arrive agentically — the business steers the goals, so the development phase can only accelerate up to a certain point. Feature Creep is a real risk: new functionality gets built simply because it is now possible.
Spec-driven development and harness engineering
Several sessions surfaced the same observation: when coding moves to agents, the work of the architect and developer becomes “harness engineering”: directing, constraining, and validating agents. Spec-driven development works in practice as a steering mechanism for agents.
An agent needs a harness, a governance and control framework built from six perspectives:
- What the agent is allowed to do: Permissions
- What context does it have access to: Knowledge base
- How it communicates: Interfaces
- How it is monitored: Guardrails
- How errors are handled: Recovery
- How it reports: Observability
Without a clear harness, an agent is unpredictable — with one it is production-ready.
The current state of Azure AI
Zure CEO Sakari Nahi offered a pragmatic overview in his presentation: Where Azure AI services stand today, where the development is heading, and how the disruption practically affects software companies. The emphasis was on business drivers, architectural models, and the challenges of governance. The architect’s role is moving ever closer to the business. The task is to take care of the architecture of the entire value chain, not just technical implementation.
Orchestration is hard but central
Microsoft’s Jouni Nieminen opened up the architecture of agentic automation concretely. The core message was: “Use structured messages between agents.” When agents communicate in a clearly bounded, structured format, orchestration simplifies, and error tracing becomes easier.
Guardrails and observability must be built in from the start, not retrofitted. Where orchestration sits, how agent responsibilities are scoped, and how tools are connected are architectural decisions that determine whether a system works in production or not.
The bottleneck shifts: From code to testing and the business
Once coding has been handed to agents, the next bottleneck is testing and acceptance and after that, the business. Feedback from customers takes its own time, and the business cannot keep pace with development.
The entire value chain and ways of working must be rethought. Again.
Every stage enriches the same context
Perhaps the most important architectural insight from the seminar: Agent-based development only works when all stakeholders share the same context. The customer’s business, product owners, and project managers must be brought to the same AI tools and context where developers already are.
Every stage, definition, design, implementation, testing, and acceptance enriches the same shared context. Not separate documents in different systems, but a single context that agents and humans build and consume together.
This is a big shift. Business, project management, and product management integrate into the same context as the technical team. No more “throwing the spec over the fence” — everything is connected to the same context.
What does this mean in practice?
- Harness engineering is the new core capability. The architect’s work shifts from writing code to designing the governance and control framework for agents: context, boundaries, validation, observability. Spec-driven development is the practical tool for this.
- Organise into small, autonomous teams. Teams of 2–3 people with flexible roles where everyone has access to the same context. Traditional process frameworks don’t work as-is.
- Build the shared context before the agents. If the business, product management, and development live in different worlds, agents don’t solve the problem, they accelerate movement in the wrong direction.
- Orchestration with structured messages. Agent-to-agent communication via structured messages, guardrails included from the start, and observability from day one. Otherwise, you don’t know what your system is doing.
We build governed cloud environments and agentic architectures that work in production. If agentic strategy, harness engineering, or modernising your development model is on the agenda, get in touch: [email protected]