Why Agentin

This site is new. Not repainted, rebuilt: different data model, different navigation, different idea of what belongs here. The name stayed, and since people regularly misread it, that is where I will start.

Two readings, both intended

Agentin means two things at once for me.

First: I build agents. Copilot Studio, Microsoft Foundry, Microsoft Agent Framework. That is half my working week, sometimes as a prototype in a customer project, sometimes as a demo on stage, sometimes as code I throw away afterwards because the idea does not hold.

Second: I am one. Not in a trench coat, but in the original sense of the word. Someone who works on assignment, gathers information, makes sense of it and passes it on. That is exactly what I have been doing for years at conferences, in books and in customer projects.

The espionage styling is a wink, not a costume. If it ever gets in the way of the content, it goes. It matters enough to me to carry through consistently, though, because it carries one thing correctly: a large part of my work consists of getting inside unfamiliar systems, working out how they actually behave, and handing that back in a form people can use.

No loose ends

The second part of the name is my surname, and that one was a gift. Enders. Keine losen Enden. No loose ends.

That is not wordplay for its own sake. It is the standard I want to be held to. An agent that runs in the demo and falls over in production is a loose end. A proof of concept without a cost calculation is a loose end. A talk that impresses everyone and leaves nobody able to do anything differently on Monday is a particularly annoying loose end.

I have seen enough projects where the hard part only started after the prototype. Governance, licence costs, operations, the question of who is liable when the agent says something wrong. These questions are unglamorous. They still decide whether a good idea turns into a system.

Five identities, not a career path

You will find five identities on this site. They look like stations. They are not. They run in parallel and all five are active.

• DIE VERBINDERIN, the connector, stands for collaboration and modern work. Teams, SharePoint, Microsoft 365. The area I have worked in longest and the subject of my books.
• DIE KONSTRUKTEURIN, the builder, stands for business applications and low code. Power Platform, Dataverse, everything business departments can build themselves if you let them.
• DIE AGENTENFÜHRERIN, the handler, stands for AI agents and assistive systems. Copilot Studio, Foundry, orchestration, multi-agent scenarios.
• DIE ARCHIVARIN, the archivist, stands for knowledge, readiness and governance. The unsexy part, without which none of this reaches production.
• DIE TECHNIKERIN, the engineer, stands for development and AI in engineering. The only identity that is deliberately vendor-neutral. What is written there holds outside the Microsoft ecosystem too.

Why this split? Because a single focus area would be a lie. I get booked for Teams topics and for agent architecture, sometimes at the same conference. Rather than pretending one developed into the other, I make it visible that these are five fields of work that depend on each other. Build agents without understanding collaboration and you build past the people. Do governance without ever having built anything and you produce rules nobody can follow.

The code names deliberately contain no product names. Products get renamed, sometimes twice a year. Azure AD became Entra ID, Azure AI Studio became Microsoft Foundry, Power Virtual Agents became Copilot Studio. An identity named after a product ages with the product.

What a dispatch is

Dispatches are what happens between the missions. Four formats, and the distinction is practical rather than decorative:

• Note: short, one fact, a brief assessment. A release, a price change, a date.
• Analysis: the classic article. Something changed, I explain what it means in practice, and I take a position.
• Reference: pieces I maintain instead of archiving. This format shows the date of the last review at the top rather than the publication date. Cost models and compliance deadlines belong here, because they move, and a two-year-old state is worse than none.
• Backstage: this one. How I work, why I do things a certain way, what went wrong.

Every dispatch hangs off at least one identity. That is not a category in the usual sense but an assignment to a field of work: the work of making that identity credible.

What you will not find here

Three things I am deliberately committing to.

No retold release notes. When Microsoft announces something, you can read the announcement at Microsoft. What you will not find there is an assessment of whether it holds, what it costs and where it breaks. That is my job.

No claim without a source. Product states move quickly, my memory is not a reliable source, and neither is a language model. Where I rely on something, the link is there, preferably Microsoft Learn or the primary source. Where sources contradict each other, I write down the contradiction instead of smoothing it over.

No recommendation without a trade-off. Every technology decision costs something. If a text lists only advantages, either I did not think hard enough or I am selling you something.

Where the rest lives

The missions are the appearances, sorted by location, with a map. The briefings are the talks themselves, with descriptions and running times, in case you want to book one. The publications are books and courses. The legend explains who is behind all of it.

And here, in the dispatches, is the work in between.

From the field. 🕶️