---
{
  "n": 37,
  "title": "Orchestrator chat with named, restricted agents and a Kanban view",
  "abstract": "A conversation with two colleagues explores turning the journal into an orchestrator that delegates to named, limited agents, shown as a Kanban board; a future idea, nothing built.",
  "refs": [],
  "seen": [
    "agent",
    "user"
  ],
  "data": {
    "kept": false,
    "revisions": 1,
    "open_until": 1790095188.6735098
  },
  "created": 1790028192.285374,
  "updated": 1790093388.673833,
  "deleted": 0.0,
  "completed": 0.0,
  "outcome": "",
  "type": "doc"
}
---
This report records a spoken conversation (mostly Dutch) between Jesse Gall and two colleagues about a future idea for agent-journal — an orchestrator chat that delegates to named agents, each with its own instructions and limits. It files the idea and the conversation as a formal record, not as a technical design.

## What the idea is
Source: journal message 1486, a pasted transcript (mostly Dutch, one colleague speaking English) of a spoken conversation between Jesse Gall and two colleagues, referred to in the transcript as Speaker 1 and Speaker 3 (addressed at points as Björn/Bjarne and once as Remmer/Rembar). Jesse's own request for this filing: 'this transcript, into a formal thing that we want to have, like a thing we will start doing in the future... It's not a design document. It shouldn't be a design, but it's more a general idea conversation.'

The core idea, as Speaker 1 put it: 'Mag communiceren met al zijn agents die hij heeft, dus al die die ook een naamgegeven zou kunnen hebben, bijvoorbeeld marketing agent, whatever.' (He may communicate with all the agents he has, agents that could also each have a name, for example a marketing agent, whatever.) Speaker 1 continued: 'op zoek naar een orchestration tool waarbij dus deze chat eigenlijk de agents orchestreert. En deze chat heeft niet echt een naam...' (looking for an orchestration tool where this chat actually orchestrates the agents; and this chat doesn't really have a name...) — to which Jesse supplied the word: 'De orchestrator.' Speaker 1 confirmed: 'De orchestrator, inderdaad. En daaronder hebben we heel veel agents die echt hele specifieke MD-structuren hebben en uitwerkingen wat je wel of niet mag.' (The orchestrator, indeed. And under that we have many agents that really have very specific MD structures and specifications of what you may or may not do.)

So the idea, in short: instead of the current chat spawning anonymous sub-agents, the main chat becomes a named 'orchestrator' that talks to a set of named agents (e.g. a marketing agent), each defined by its own instruction file (an MD/document) stating what it may and may not do.

## The problem it solves, and why they want it
Speaker 1 named the problem directly: 'ik denk, het probleem wat je oplost is voornamelijk context overflow' (I think the problem you're solving is mainly context overflow), adding that a task should be split accordingly: 'voor de ene taak, je moet het op die manier ook opsplitsen.'

He illustrated with a contrast. Code work benefits from one agent holding shared context: 'als je bezig bent met het ontwikkelen van code, dan wil je niet drie agents hebben die een gedeelte van de code doen omdat je dan heel veel context gedeeld wil hebben, dus dan kan je net zo goed één agent gebruiken.' (if you're developing code, you don't want three agents each doing part of the code, because then you'd want a lot of shared context, so you might as well use one agent.) But other work has no such overlap: 'een afbeelding, ons logo veranderen in de website of ons logo veranderen in het platform, dat zijn, daar zit geen context overlap in, toch?' (changing our logo on the website versus changing our logo in the platform — there's no context overlap there, right?) — 'Dus dat is meer een beetje waar ik denk ik, waar je ze in zou scheiden.' (So that's roughly where I think you'd split them.)

He tied this to how his own organization wants to work: 'wij willen het volledig agentic doen in de organisatie zelf... hé, we hebben een nieuw logo, fix het. Dan moet hij natuurlijk een marketing agent gebruiken om onze website aan te passen, maar hij moet ook onze coding agent aanpassen of gebruiken om bijvoorbeeld het platform te updaten.' (we want to do it fully agentically in the organization itself... hey, we have a new logo, fix it. Then it naturally needs a marketing agent to change our website, but it also needs to use our coding agent to update the platform.) 'Dus dat zijn echt compleet andere rolverdelingen. Dat zou je niet door één agent laten doen.' (Those are completely different role divisions. You wouldn't have one agent do that.)

He generalized the reasoning to domain separation: 'Dus allerlei optimalisatie loops of facts die je opbouwt binnen een bepaald domain, zijn alleen maar relevant voor dat bepaalde domain.' (Any optimization loops or facts built up within a given domain are only relevant to that domain.) And: 'hoe marketing werkt, dat is niet afhankelijk van hoe engineering werkt. Ze hebben een eigen methodiek daarvoor.' (how marketing works doesn't depend on how engineering works. They have their own methodology for it.) He compared it to human organizations: 'zoals we met mensen in organisaties zien, er is natuurlijk communicatie tussen de domains, alleen eigenlijk krijgen ze een opdracht van bovenaf... en die dragen ze gewoon op hun manier uit.' (as we see with people in organizations, there is of course communication between domains, but really they get an instruction from above... and each carries it out in their own way.)

A second example, given at length by Speaker 1, was a feature rollout that customers had asked for: beyond the coder implementing it, he wanted a separate branch of agents (not the coder, not the orchestrator itself) to notice from data sources ('ik zie hier in Pipedrive of andere data sources... dat bepaalde klanten hierom vroegen') that customers wanted it, and then decide to set up a mailing list or write a blog post — work that 'staat in ieder geval los van wat de coder gaat implementeren.' He noted this kind of follow-up is often skipped in practice for lack of time, but would ideally happen: 'Ja, idealiter wel, maar daar hebben we geen tijd voor, dus dan doen we dat niet. Maar dat zouden we wel willen doen.'

Jesse's own practice was more cautious about splitting, and he said so directly, without it being resolved: 'ik zelf heb vaak het idee... dat je dan één agent alles laat doen en die andere agents laat je enkel research doen... Dus ik heb persoonlijk altijd maar één development agent en die dan wel research laat doen door andere agents.' He also warned that cross-checking between agents costs context: 'als die agent een gecalculeerde... keuze wil maken op wat de sub-agents wel of niet goed bezig zijn, dan moet hij alsnog gaan kijken in wat ze doen... dan moet je al die context weer inladen.' Speaker 1 answered that this is really about expertise separation, not general practice: 'Nee, nee, nee, nee, nee, dus echt, echt expertise afgebakend, zeg maar.'

## Named agents, their instruction files, and limits
Speaker 1 described what should sit under each agent: 'eigenlijk wil je dus op... skills checks, rules en documents wil je ook kunnen definiëren onder agents.' (you actually want skills, checks, rules and documents to be definable under agents.) Jesse replied that today this is scoped to the project as a whole, not per agent: 'momenteel is het project scope.'

Jesse explained what an agent already is technically in the system: 'een agent is in principe ook een document... het is een beetje gek, want dit is eigenlijk een markdown file, maar er zit dan een header van dingen in.' (an agent is in principle also a document... it's a bit odd, because it's actually a markdown file, but it has a header of things in it.) He said each spawned sub-agent already gets such a file: 'elke keer als ik een sub-agent spawn, dan krijgt die sub-agent een agent file, waar hij dus ook weer dingen mee kan.' Because the whole system is document-based, he judged that giving an agent a fixed 'profile' would not be hard: 'dat het systeem werkt in je documents... jij bent agent X en dit is jouw profiel. Dat is, zeg maar, niet heel moeilijk af te bakenen.'

On enforcing limits (Speaker 1's deploy-agent example: 'één iemand is verantwoordelijk voor deploys, en jij mag alleen dit doen'), Jesse pointed to hooks as the mechanism: 'dat gaat, moet je dus via hooks, moet je dat dus afbakenen, denk ik, dat je gewoon ook gewoon hard crasht of hard weigert wanneer ze dingen doen die ze niet mogen.' (that has to be scoped through hooks, I think — that it simply hard-crashes or hard-refuses when they do things they're not allowed to.) He added: 'Hooks zijn gewoon events, en Codex en Cloud laten je een tool use weigeren.' (Hooks are just events, and Codex and Claude let you refuse a tool use.) He judged this feasible: 'Het is eigenlijk gewoon heel simpel.'

A related, separate idea surfaced from this same exchange: a new resource type for how agents should talk to each other. Jesse: 'dat is dan weer een mooie nieuwe, een soort van nieuw idee voor een resource, en dat is een protocol... hoe praat je met dit, of hoe ga je met dit om.' (that's actually a nice new idea for a resource, and that is a protocol... how do you talk to this, or how do you deal with this.) This was offered as a new kind of thing the system could support, not something that exists yet.

## Agents talking to each other, and running in parallel
On agent-to-agent messaging, Jesse said: 'ik weet niet of Codex dit heeft, maar Claude kan onderling met zijn agents in hetzelfde netwerk praten. Dus ik kan zeggen: stuur bericht van deze guy naar deze guy.' (I don't know if Codex has this, but Claude can talk between its agents in the same network. So I can say: send a message from this guy to this guy.) He noted a limit: cross-server messaging isn't native, but could be bridged: 'cross-server kan dat natuurlijk niet, maar dan kan je het wel met overbruggen door middel van een request naar een andere journal te sturen.' (cross-server obviously can't do that, but you could bridge it by sending a request to another journal.) Speaker 1 said he wasn't sure whether the Codex CLI supports the same thing, only that Codex desktop can send chats to other chats: 'Ik weet niet of de Codex CLI dat zelf ondersteunt... Ik weet dat Codex desktop kan dat wel, maar ik weet niet hoe zij dat in de desktop doen.' This was left unresolved.

On whether agents should run as one process or several, Speaker 1 was clear: 'Nee, het hoeft niet één proces te zijn, zeker niet. Ik denk dat het beter is, zelfs losse processen.' (No, it doesn't have to be one process, definitely not. I think it's better, even separate processes.)

Jesse floated an 'orchestrator mode' as a possible mechanism: a profile that, once switched on for an agent, makes it delegate everything rather than do work itself, driven by instructions injected via the agent's own agents.md/rules: 'kan je dan inderdaad een soort van orchestrator mode hebben, wat, en als die aanstaat, dan wordt dat als, dat zijn, zeg maar, zijn profiel... dus dan weet hij ook wat hij moet doen, eigenlijk automatisch, dus dat hij eigenlijk niks zelf schrijft.' Speaker 1 rephrased this as a project-level (journal-level) setting: 'dat je de... journal, kan je dan, zeg maar, in twee modi zetten, of in orchestrator mode of in sub-agent mode.' Jesse agreed this was roughly the idea ('Ja, dat is een beetje het idee, ja'), described it as connected agents the orchestrator could query for status ('kan die gewoon instructies geven, en dan kan hij ook ophalen wat ze aan het doen zijn momenteel').

On running several plans/agents in parallel today, Jesse said this mostly doesn't happen because everything currently runs in one project: 'want ik heb dit, dat komt ook omdat alles nu in één project draait, en als je dan... naast elkaar wil laten lopen, dan moet ik eigenlijk workstreams, of... subagents.' Asked why not simply run multiple agents in the same repo, he said conflicts are the reason he avoids it, and that using several agents costs more tokens than reconciling one agent's work: 'dat is gewoon, ik gebruik mijn agents vaak op een andere manier, maar ik heb altijd research agents, en een agent die bouwt... het kost veel meer tokens om meerdere agents te laten doen dan één agent vaak.' He acknowledged tags exist for this ('Ja, dat klopt, ja') but said building it out was simply not where his focus had been: 'ik heb dat gewoon niet, het was niet de focus van mij om het puur multi... maar dat heeft er ook mee te maken, dat was mijn cheating.'

Environments were discussed as the mechanism that could give each parallel item of work (e.g. each Kanban item) its own journal process: 'Ja, dat kan, ja, dat is zeker mogelijk, ja, je kan nu ook al nieuwe environments starten.' But Jesse was explicit this is not properly scoped yet in the current (version 2) build: 'ik heb dat nog niet genoeg uitgewerkt in versie 2, dat is een beetje het ding... ik moet het wel goed scopen via een ding.' He demonstrated live that messages currently leak between environments that should be separate: typing in one environment, 'komt hij dan bij beide aan, ja, dat is een beetje het probleem.' This was left as a known, unfixed gap, not a decision.

## UI changes mentioned
Speaker 1 proposed making agents/roles clickable in the sidebar: 'wat ik dus meer bedoel in de zin van dat als je hier links in je menu dus, dat je ook letterlijk op de rol kan klikken.' (what I mean is that here on the left in your menu, you could literally click on the role.) Jesse's response: 'Ja, ja, dat kan, dat zou een goed idee zijn, ja. Dat kan momenteel nog.' (Yes, that's possible, that would be a good idea. That's not there yet at the moment.)

Speaker 1 then proposed a top-level, visual overview of agents talking to each other — a 'helicopter view': 'dan zou je bijvoorbeeld ook bijvoorbeeld een helicopter view kunnen hebben, waar je gewoon visueel ziet hoe de agents ook met elkaar aan het praten zijn.' He described it as 'een web aan agents' (a web of agents) where you might not even need to type to the agents directly, but could see, given a plan and its tasks, which agents were collaborating to close out which responsibilities. Jesse restated it as: 'dus dat er dan een trail is van wat ze hebben gestuurd naar elkaar, dat je dus eigenlijk een web krijgt van gewoon een soort van flowchart van: hé, deze doet dit, dat doet dat, ja, dat het zichzelf ontdekt.' (so there'd be a trail of what they sent each other, so you'd get a web, a kind of flowchart of: hey, this one does this, that one does that — that it discovers itself.) Speaker 1 tied this directly to visibility into rule-following, e.g. seeing that a deploy agent was actually used for a deploy, as it should be required to be: 'oké, ja, hij heeft inderdaad de deploy agent gebruikt om te deployen daadwerkelijk, want dat mag hij anders ook niet, zonder deploy agent.' No concrete UI design was agreed; this stayed at the level of a wish.

Later the discussion turned to a Kanban-style board. Speaker 1 suggested a Kanban tab as possibly simpler than integrating an external tool: 'is het misschien zelfs nog veel makkelijker om te zeggen van, we gaan een Kanban tabje toevoegen waardoor je eigenlijk alles inhouds hebt.' Jesse expressed a preference for building it in-house rather than integrating an external tool: 'ik persoonlijk zou ik, ik ben altijd voor mijn eigen tools liever dan extern, dus ik zou hier gewoon zeggen: maak het Kanban tabje.' He reasoned that a Kanban board is fundamentally just a list of to-dos: 'een Kanban is gewoon een lijst met to-do's.'

Speaker 1 framed the deeper point as being about what leads the interaction — not the chat, but the board: 'volgens mij is het voornamelijk het idee dus dat niet de chat de lead heeft, maar de Kanban is de lead... het voedt elke keer de agent met nieuwe shit.' Jesse responded that something like this already exists in the journal today, even if not visually a Kanban: with auto-mode on, the journal already tells the agent what its next to-do is after each step: 'de journal gaat nu vertellen wat de volgende to-do is die hij elke keer moet volgen... het is niet helemaal, zeg maar, een Kanban, maar de journal gaat nu vertellen wat de volgende to-do is.'

They further discussed the Kanban as a purely visual layer on top of existing plans: Speaker 1 — 'je zou dus in principe kunnen zeggen van: we maken een Kanban als echt puur visualisatie... waarbij je plannen ziet als items.' Jesse agreed a plan would be the card/item shown: 'ja, oh, dat hele plan is gewoon één ding wat je dragt' (yes, that whole plan is just the one thing you drag), and that opening a plan-as-card would reuse the existing side panel: Speaker 1 — 'als je op een plan drukt, dan krijg je dezelfde side panel, dan kan je gewoon die logica gebruiken, het is puur een visuele weergave.' The extra value Speaker 1 saw was a per-item indicator that human interaction was needed, e.g. an exclamation mark: 'per item, dus per plan... zag of hij bezig was, of een uitroepteken stond van: hé, hier is interaction nodig.'

Jesse also described existing human-in-the-loop UI he demonstrated live during the call: questions the agent asks that the user answers through the UI, commenting on any part of a plan or to-do (since everything is a document), and selecting text to leave a targeted comment: 'als hij iets niet weet, of op mij wacht, dan kan ik dus hier een antwoord geven, gewoon door de UI... kan je op alles commenten, basically, je kan ook letterlijk tekst selecteren.' He also noted the agent can pre-populate buttons in its own messages, e.g. to offer a merge action when done: 'hij kan zelf... iets vragen, en daar zelf buttons en zo in zetten, dus wanneer hij dan klaar is, kan ik aan hem vragen van: hé... kan je een bericht klaarzetten met de knoppen om hem te mergen.' He also showed, live, a UI bug where a to-do would not open from search/sidebar ('dat is wel mooi, maar... die fucking to-do opent' / 'er is een UI bugje, wat irritant') — noted here only as something observed during the demo, not a design decision.

## What they compared it to or referenced
Symfony. Speaker 1 introduced a tool their side has been building, called Symfony, as a close but simpler comparison: 'Symfony is in principe gewoon eigenlijk dit project wat jij doet, alleen dan veel simpeler, en het is een orchestrator tussen je Kanban van bijvoorbeeld Asana en processen van Codex, of processen van Claude.' (Symfony is basically this project you're doing, only much simpler, and it's an orchestrator between your Kanban, e.g. Asana, and Codex processes, or Claude processes.) He described its flow: an item is created in an Asana Kanban ('yo, shit kapot' as an example), Symfony builds context by chatting on that Asana item, writes requirements, and posts a plan back into the Asana item. He described four standard columns as an example — backlog, plan, in process, done — with the agent only allowed to move an item as far as 'plan' and a human moving it to 'in progress' as approval: 'als jij een to-do staat, dan maak jij een plan, en dan zorg jij dat hij in plan komt te staan, stap, en dan doe je niks meer, en als human ben jij hem aan het in progress zetten.' He also described a human-review/PR-merge step: when Symfony's agent stops, it puts the item in human review and messages, e.g., 'ik heb een PR klaarstaan, mag ik hem mergen, ja of nee,' after which it can walk the human to the GitHub page to squash-and-merge, 'met alle CI checks die erbij horen.' Jesse replied that the journal can already do an equivalent (asking a question with buttons prepared for the answer), but treated the comparison as informative rather than settled.

Asana and Linear. Speaker 1 referenced these as more intuitive existing Kanban UIs: 'de UI van een Asana of een Linear is wat intuïtiever, omdat je gewoon letterlijk die Kanban's hebt en je versleept ze van de een naar de ander.' (the UI of an Asana or a Linear is somewhat more intuitive, because you literally have the Kanban columns and drag them from one to another.) Jesse said he preferred building an equivalent in-house rather than integrating Asana (see the UI-changes section above).

Pipedrive. Used by Speaker 1 as an example data source an agent might check to notice customer demand for a feature: 'ik zie hier in Pipedrive of andere data sources, zie ik dat bepaalde klanten hierom vroegen.'

Sentry. Speaker 3 proposed connecting production error monitoring (Sentry) to the journal as an automatic ticket source: 'kun je het ook automatiseren door het bijvoorbeeld te koppelen aan een Sentry waarin een error wordt geplaatst van... en op dat moment kan... de webhook wordt juist gepost op de journal webpage... maak dan gelijk een ticket aan... met gewoon de hele trace stack erin.' Jesse responded that this would be a small, feasible feature (a recurring job/listener spawning an agent to reformat the issue and set up a new plan), estimating it at about half an hour to an hour of work, but flagged a practical doubt about whether it's a good idea to let others post tickets that immediately start his machine building: 'dat weet ik niet of dat heel handig is, dat je gewoon in het midden van dingen gaat posten, en dat mijn computer, laptop dan allemaal dingen aan het bouwen is.'

Workflows and integrations (demonstrated live, not new ideas but shown as relevant existing capability). Jesse showed the existing workflow/integration feature, where an agent reads an integration's available actions and proposes usable 'flows' built from them (demonstrated with a Slack integration), and a live demo of an 'incident desk' orchestrator workflow node handling a mock alert end to end and producing a reusable blueprint step plan. Speaker 3 connected this to the Sentry idea, suggesting an outgoing webhook trigger feeding the Kanban board so routing (since triggers are 'altijd redelijk van dezelfde categorie') could be tested and monitored directly in a journal. Jesse noted workflows would mainly be for linking the colleagues' own services together visually rather than in code, and that a plugin is technically simple ('een plugin werkt eigenlijk heel simpel, gewoon een JSON veld die events ontvangt'), so any of their programs could in principle become a plugin into the journal — but he was not sure the workflow-to-journal link (talking back to the journal from a workflow node) exists yet: 'ik weet nog niet of, ik heb nog niet mogelijk, volgens mij heb ik de workflow, ik kan nog niet terugpraten naar de journal, trouwens, weet ik niet zeker.'

## Open questions and what was left undecided
Several points were raised and explicitly left open, with no decision reached in the conversation.

Whether to build an internal Kanban or integrate an external tool (Asana/Symfony) was discussed with a leaning, not a decision. Speaker 1 asked directly: 'is het een idee om ook een soort van Asana hierin te integreren, of zou je zeggen... is het misschien zelfs nog veel makkelijker om te zeggen van, we gaan een Kanban tabje toevoegen.' Jesse leaned toward building it himself ('ik ben altijd voor mijn eigen tools liever dan extern') but this was a personal preference stated in the moment, not agreed as final with the colleagues, who separately said they would go write up their own requirements document.

Whether one 'uber agent' with full context, or many separated, restricted agents, is the right general approach was argued both ways and not settled. Jesse: 'ik doe dat vaak wel hoor. Ik heb gewoon één... Uber agent die dus eigenlijk alle context heeft.' Speaker 1 pushed back that for their case (marketing vs. engineering, unrelated domains) that doesn't fit: 'dat zijn echt compleet andere rolverdelingen. Dat zou je niet door één agent laten doen, nee.' Jesse ended this sub-thread noting a possible middle path (one orchestrator delegating to sub-projects that don't need to know about each other) but this was offered as a thought, not a design: 'ik denk dat je misschien één agent hebt, de orchestrator, die dus weet: ik ben transportklok, heel simpel, en die delegeert gewoon naar zijn sub-projecten.'

Whether Codex CLI supports agent-to-agent messaging the way Claude does was left as an open unknown for both speakers (see the agents-talking-to-each-other section) — 'Ik weet niet of de Codex CLI dat zelf ondersteunt.'

How exactly per-agent scoping of skills, checks, rules and documents would work was raised as a want by Speaker 1 but Jesse only confirmed the current state (project-scoped, not agent-scoped) and that it 'is niet heel goed' (not great) as is — no mechanism was designed in the conversation.

How multiple agents/plans would run in parallel without conflicting, and how environments would be scoped so that messages, to-dos, plans etc. do not leak between them, was raised and shown live to be currently broken/unfinished: 'ik moet het wel goed scopen via een ding.' No fix or design was agreed, only that it 'is niet heel moeilijk.'

Whether it is a good idea, practically, to let colleagues post tickets that immediately trigger Jesse's own machine to start building (the Sentry-to-journal idea) was raised by Jesse as a doubt, not resolved: 'dat weet ik niet of dat heel handig is... dat mijn computer, laptop dan allemaal dingen aan het bouwen is.' Speaker 3's proposed answer — host it themselves as soon as possible — was the direction, not a firm decision reached together in this call.

Whether the workflow feature can currently message back into the journal was stated by Jesse as something he wasn't sure of: 'ik kan nog niet terugpraten naar de journal, trouwens, weet ik niet zeker.'

Overall framing, stated explicitly by Jesse near the end, was that nothing here is fixed and everything depends on the colleagues writing down what they want: 'als jullie, zeg maar, een soort van top-down idee hebben hoe je dat het liefst wil hebben, dan kan ik daar wel een beetje op daar dingen voor implementeren, maar je mag het ook natuurlijk zelf... in principe is alles mogelijk, want het is zo fucking simpel eigenlijk.'

## Where it stands
This is a future idea from a conversation, not a plan, not a spec, and nothing described in it has been built as a result of this call. The call itself was largely a live demo of the existing journal (plans, to-dos, auto-mode, comments, questions with buttons, workflows/integrations) alongside a conversation about where it could go, mixed at points with unrelated business matters (a payroll correction file, and general project talk) that are not part of this idea and are not filed here.

Jesse's stated posture was that almost anything discussed is technically easy given the document-based architecture, but that the real work is deciding on process, not code: 'het uitdenken van processen is het meeste werk, denk ik, om, weet je, hoe wil je dingen laten lopen.' He was explicit that he needs the colleagues' own written, functional (not code-level) plan before building toward their vision: 'als jullie, zeg maar, een soort van top-down idee hebben hoe je dat het liefst wil hebben, dan kan ik daar wel een beetje op daar dingen voor implementeren.'

The agreed next step, stated at the end of the call by Speaker 3, was that the colleagues would write a functional-requirements document and then host the project themselves once possible: 'wij gaan, gaan we zitten voor zo'n document, van functional requirements wat we nodig hebben, en nou, zodra het beschikbaar is om te hosten, dan gaan wij het gewoon meteen hosten en laten we het je weten.' (we're going to sit down for such a document, of functional requirements that we need, and once it's available to host, we'll host it right away and let you know.) Jesse's reply: 'Oké, is goed.' Separately, hosting the project on a shared server (instead of Jesse's local machine) so both sides have access was raised by Speaker 1 as something they'd want soon, and Jesse confirmed it as a next step already on his own list, unrelated to this specific idea: 'dat is inderdaad het volgende stap hoor, wat ik wil doen, is dat ik inderdaad dit ook online... dat hij dan weet dat dat de source of truth is.'

No timeline, owner, or scope was fixed for the orchestrator/named-agents/Kanban idea itself beyond this: the colleagues write up what they want, and Jesse judged it feasible to build once that is clear.