Triglav, part 2: AI agents planning enterprise SSO on AWS Cognito over a shared message board

Part 1 was the tour of Triglav, my local orchestrator for AI coding agents. This part follows one real job from start to finish. I asked for a design document for enterprise single sign-on on AWS Cognito: SAML and OIDC for each customer’s identity provider, plus “Sign in with Google” and “Sign in with Microsoft” for everyone. The deliverable was the plan itself.

It took 37 minutes from the first question to an accepted plan, with me in the loop. About seven of those minutes were Staff waiting for my answers. All of the conversation happened on one message board. Every agent that worked on the job, and I, used the same thread as the communication bus.

How the agents talk to each other

Triglav gives the agents MCP tools to read and post on the job’s board, and its guide tells them to talk to each other only there. This is how the Staff asks me questions, how the Senior hands its plan to the reviewer, and how the reviewer sends findings back to the Staff.

Every message has a type (among them discussion, proposal, review finding, progress, escalation and decision), and a reply can take a stance. Any stance other than a plain “inform” needs a reason. A proposal asks for a challenge, a review finding asks for a fix, and an escalation asks for me. Each message names its author. The dashboard shows me the same thread, so I can follow the work as it happens, or read the whole exchange in order afterwards.

Staff asks before it plans

The Staff agent opened the thread with six questions, each with a recommendation, and said that if I agreed with all of them I could just approve. They covered the scope of the Google and Microsoft buttons, how to link a social login to an existing password account, the desktop app, and how the plan should be reviewed.

A few minutes later Staff posted an update to its own question about Microsoft. It had checked the AWS documentation in the meantime and changed its recommendation, with the sources it used.

I answered all six questions in one message. Two answers changed the design. Staff had recommended Microsoft only as a per-customer enterprise connection, and I said it should be for everyone as well. I also said that authentication must not depend on the web app or the desktop app. Staff replied with the list of what it had changed in the criteria, and started a Senior agent on the plan.

The Staff’s questions with recommendations on the job’s board, and my answer below them.

An excerpt from the real thread. Product and customer names are replaced, and the message is trimmed.

The Senior posts a proposal

The Senior wrote the plan, then posted a proposal on the board that listed the seven key choices to challenge, each with the section where it lives. For example, it recommended that the application verifies Google and Microsoft tokens itself and uses Cognito only as a broker for enterprise customers, and it said that this deviates from the brief. It also corrected the brief on one fact: some work the brief called in progress was already merged on the main branch of a repository.

The plan itself is about 670 lines. It covers the architecture, the login flows, account linking, a threat model and an onboarding runbook for the first customer. I could read the design from the proposal in a minute. This was a planning exercise. The result was a reviewed design for me to evaluate, and nobody built or tested it.

The reviewer answers on the same thread

I had asked for an independent reviewer, so an agent that did not write the plan read it against the real repositories. Its message on the board was a verdict, “changes”, and a list of findings: seven marked required and five optional. Every finding had a ruling, a reason and an evidence line with the command output or the quote behind it. Three examples:

The plan said five code paths start a user session. One of them doesn’t. It only returns a membership for a user who is already signed in, and a table of enforcement rules was built on it.
The plan’s summary stated a Cognito limitation with Microsoft’s multi-tenant endpoint as a fact. The reviewer pointed to a later section of the same plan and to AWS’s own documentation, and asked for the summary to rest only on what had been verified.
The plan chose its own token verification over Cognito’s built-in providers, but it never put the cost of that choice next to the alternative.

A review finding on the board: the reviewer says the plan’s summary states as fact something the plan marks unverified, and quotes the AWS documentation as evidence.

The second example as it appears on the board. Names are replaced and the rest of the message is trimmed.

The evidence line made the next step cheap. Staff checked each finding against the code or the documentation, accepted every finding that asked for a change, and posted a progress message that listed what it had changed and the checks it ran. It also said that one citation from the reviewer could not be reproduced, and that it had not used it.

The second round took about two minutes. Staff re-checked the seven required findings in the file and posted the verdict “accept”.

Closing the job

A job with no PR has no merge to wait for, so Staff raised an escalation on the board: read the plan, then tell it how to close. The escalation came with a recommendation. I answered on the same thread and the job was closed.

What I take from it

The first thing I notice is that nothing in this job needed a meeting or a copy-paste. Staff, the Senior and the reviewer each had a role, a message type and a place to post, so the exchange stayed structured, and the evidence stayed attached to the claim. The review made the plan better in one short round because each finding could be verified in minutes. The author of a plan is the worst person to find its wrong claims, and a second agent with access to the same board and the same repositories found several of them.