🧠Impostor Syndrome Workflow.

I Built a Multiagent Workflow to Understand My Impostor Syndrome
A dark, dry, self-deprecating field report from a not-computer-scientist who still ships things

If you have ever felt like your job title is a clerical error that will be corrected publicly, welcome. You are not broken. You are just running a brain that does not have a single CEO. It has a committee.

My committee is loud. One member is convinced I am one pull request away from being exposed as a fraud. Another member wants to build things at 2 AM like the rent is due in the morning (it is). Another member keeps a dusty folder of childhood failures and opens it at the worst possible time, like a horror movie librarian with a keycard.

For years I called this anxiety. Then I started building multi-agent AI workflows. And I realized something slightly uncomfortable: my brain already behaves like an agentic system.

So I did what any emotionally mature adult would do. I tried to formalize it. With roles. With message passing. With timeouts. With observability. And yes, sometimes with a YAML file, because apparently I cannot be helped.

This is an autobiographical article, but the goal is not to talk about me. The goal is to show you a model that is useful: how human thinking can be understood as a workflow of specialized parts. And how that model maps almost perfectly to the problems we are all hitting when we try to ship multi-agent solutions in production.

Also, I will talk about impostor syndrome, because mine deserves a salary.

A warning: this is not therapy. It is an engineering perspective on cognition, with a bit of ethology, and just enough self-deprecation to keep me from taking myself seriously.

Why I do not trust my own legitimacy

I am not a computer scientist. That sentence alone can trigger my internal compliance department.

I also failed at school. Not in the romantic "I got a B once and it changed my worldview" way. I failed repeatedly. Four times across my school career. I finished late. I learned early that the world has timelines, and I am often not on them.

My school path was basically a stress test:

• I would try, then fail.
• I would decide the failure proved something essential about me.
• I would eventually try again, usually with a slightly different strategy and a lot more shame.
• I would pass, but the passing never rewrote the story. It just created a new story: "You passed, but late, so it does not count."

That pattern is important. It is not about school. It is about how the brain updates beliefs. A human can gather new evidence and still keep the old model, because the old model is emotionally sticky.

Later, I did what many people do when they are young and trying to become someone else. I put substances into my brain. I am not going to glamorize that. It affected my perception and my sense of what is real. It also gave me a permanent appreciation for how fragile "reality" feels when your brain chemistry is off by a few milligrams.

So now I have this fun setup:

• I have real technical skill that I use daily.
• I have a biography that my nervous system interprets as "evidence you should not be here."
• I have a brain that can generate vivid alternative timelines where everything collapses.

That is impostor syndrome for me. Not a cute insecurity. More like a background daemon. It waits for a trigger, spikes CPU, and then forks twelve threads called "What if they notice."

A short autobiography in failure mode

If you want the clean version of my life, it is boring: I studied, I worked, I built things, I learned, I built more things. The messy version is the real one. And the messy version is where impostor syndrome gets its fuel.

The messy version looks like this:

• I started as someone who could not make school fit.
• I became someone who learned to improvise around the system.
• I picked up a deep sense that competence is temporary and conditional.
• I got good at observing, adapting, and explaining. (This is the ethologist in me, before I even knew the word.)
• I eventually ended up building complex AI systems, which is a hilarious destination for someone whose inner voice still says "you are not academic enough."

Here is a small, honest moment: I have shipped real systems, solved real problems, led real projects, and I can still be destabilized by a single sentence from someone smarter than me. Not an insult. Just a neutral comment like "why did you choose that approach." My body hears it as "the trial has started."

This is why impostor syndrome is so irritating. It does not care about the objective record. It cares about perceived social risk. It is not measuring your skill. It is measuring your exposure.

I also think my history shaped a specific cognitive style: I learned to survive by learning fast, reading rooms, and finding alternative routes. That can look like talent from the outside. From the inside it often feels like improvisation under threat. The Builder loves it. The Auditor weaponizes it.

Here is a paradox: failing early can produce a strong builder, but it can also produce a permanent fear of exposure. You become capable, but you do not become safe.

And "safe" is what the impostor agent is trying to optimize. It does not care about achievement. It cares about avoiding humiliation.

That is why success can feel worse than failure. Failure confirms the story you already know. Success demands a new story. New stories are unstable.

---

The ethologist view

Before I wrote code professionally, I studied ethology, the science of animal behavior. Ethology taught me something that software engineers sometimes forget: behavior is not a monolith.

In animals, what you observe is the outcome of competing internal systems interacting with the environment. Hunger pulls one way. Fear pulls another. Social drives pull another. Past reinforcement biases decisions. Context changes everything. The animal is not asking, "What is the true me?" The animal is selecting an action that is good enough to survive right now.

Ethologists look at behavior as:

• modular
• triggered by cues (sometimes stupid cues)
• influenced by internal state
• shaped by reinforcement and social feedback
• constrained by energy and time

Also, animals do not "solve life." They run policies. That is why a cat can be brave around a vacuum one day and run like it saw the devil the next day. Context and state changed, and the policy flipped.

If you want a practical ethology cheat sheet for human cognition, here are a few concepts that translate shockingly well:

Sign stimulus and releasing mechanism
Animals often respond to specific triggers that release a behavior. The trigger can be small. The response can be huge. Humans do this too. A Slack message with "can we talk" can release a full physiological cascade. The message is the sign stimulus. Your nervous system is the releasing mechanism. The behavior is your brain building a courtroom.

Fixed action patterns
Some behaviors run like scripts once triggered. You start doomscrolling. You do not decide to stop. The script runs until something interrupts it. This is not weakness. It is automation.

Displacement behavior
When animals are conflicted (approach and avoid at the same time), they sometimes do something irrelevant: grooming, pecking the ground, moving in circles. Humans do this too. When I am afraid to ship, I reorganize files. When I am anxious about a meeting, I research irrelevant edge cases. The displacement behavior feels productive. It is not.

Supernormal stimuli
Some stimuli hijack the system because they are exaggerated. Social media is a supernormal stimulus for social validation and threat detection. AI hype cycles are supernormal stimuli for status and belonging. Your brain was not built for it. It reacts anyway.

Tinbergen's four questions
Ethologists often ask four kinds of questions about behavior: what causes it now, how it develops, what function it serves, and how it evolved. For impostor syndrome, those questions are gold. It has immediate triggers, a developmental history, a protective function, and an evolutionary logic. That does not mean it is correct. It means it is explainable.

The core lesson: the brain is not a unitary narrator. It is an orchestration layer coordinating multiple subsystems.

---

The AI view

Now jump to 2025. Everyone is building multi-agent systems. It is exciting. It is also the fastest way to discover why brains evolved the way they did.

The first time you build a multi-agent workflow, you get a dopamine hit:

• one agent writes
• another agent critiques
• another agent fetches context
• another agent decides
• everything feels alive

Then you try to ship it.

Then you discover:

• agents duplicate work
• interfaces drift
• tool calls fail silently
• critics never stop critiquing
• planners plan forever
• memory grows until it becomes a landfill
• a single slow model turns your "parallel" system into a linear queue wearing a hat
• evaluation is vague because outputs are non-deterministic
• nobody trusts the results enough to use them in a regulated environment

That list is basically my internal life.

So I started treating my own thinking as a workflow. Not because I love metaphors, but because it gives me levers. If you can name a subsystem, you can route it. If you can route it, you can timebox it. If you can timebox it, you can ship.

Here is the mental model:

• I am the orchestrator, but I am not always in charge.
• I have internal agents with specific roles.
• Impostor syndrome is not "me." It is an agent with a job and poor UX.
• The solution is not to delete the agent. The solution is to constrain it and make it useful.

This is also the lesson for multi-agent AI. You do not remove the critic. You make it bounded and accountable.

---

The moment I realized my brain was a workflow

The moment was not mystical. It was during a project where I had to deliver something ambiguous, with stakes, under time pressure. That combination is my impostor syndrome's preferred cuisine.

I had two experiences in parallel:

• outwardly, I was building an orchestration runtime for agents
• inwardly, I was watching my own cognition behave like a badly configured swarm

Externally, the workflow looked like:

• parse input
• route to specialized components
• validate outputs
• store traces
• iterate

Internally, the workflow looked like:

• interpret the situation as threat
• pull memories of past failure
• generate catastrophic predictions
• attempt to prepare by doing more and more
• get tired
• interpret tiredness as proof of incompetence
• repeat

At some point I thought: "This is just a pipeline with no guardrails."

And that was the shift. The question stopped being "how do I feel better" and became "how do I change the routing."

That framing is the entire article.

My internal agents

Below are the representative agents. These are not mystical archetypes. They are functional components. Each one is useful in the right context and destructive in the wrong one.

If you recognize yourself, congratulations. You are running the standard human firmware.

Agent 1: The Auditor

The Auditor is my internal adversarial reviewer. It thinks it is protecting me. It is not entirely wrong. The delivery is just brutal.

What it says:

• "You are not qualified."
• "You got lucky."
• "They will ask one question you cannot answer."
• "If you ship now, you will regret it forever."
• "Everyone is polite, but they are keeping score."

What it is trying to do (its positive intent):

• prevent public humiliation
• prevent reputational collapse
• force rigor
• catch weak assumptions
• reduce variance in outcomes

When it is actually useful:

• design reviews
• security and failure mode thinking
• pre-mortems
• deciding what not to promise
• asking "what could go wrong" before it goes wrong

Failure mode:

• it never terminates
• it demands certainty in a world that runs on probability
• it blocks shipping
• it converts excitement into dread
• it mistakes preparation for control

Multi-agent analogy:
The Auditor is the critic agent. In AI, critics are essential. But if your critic is not timeboxed, it becomes an infinite loop. In humans, the same thing happens.
One technical note that matters: critics optimize for avoidance. Builders optimize for progress. If you let the avoidance optimizer run the system, you get safety at the cost of reality. You also get resentment.
Incident report: when The Auditor spikes
This is the exact moment where someone says, "You are an expert," and my brain replies, "That seems illegal."
In multi-agent terms: the critic starts producing unbounded tokens. The orchestrator loses control. The system becomes a panic generator.

A typical spike looks like this:

• I receive praise.
• The Auditor interprets praise as increased surveillance.
• It predicts a future audit.
• It demands immediate upskilling, on everything, now.
• It produces a list of hypothetical questions a stranger might ask me in six months.
• I attempt to answer all of them today.
• I become exhausted.
• Exhaustion becomes "evidence."

My fix is not "calm down." My fix is a protocol:

• run Auditor for 5 minutes
• force it to output 5 actionable risks max
• each risk must include one realistic mitigation
• route those risks to the Builder
• stop

This sounds simplistic. That is the point. Most complex systems are stabilized by simple rules.

Agent 2: The Gatekeeper

This agent enforces legitimacy rules that were never officially published, but feel binding anyway.

What it says:

• "You do not have the right degree."
• "Real engineers know theory."
• "Someone younger will embarrass you."
• "You cannot say you built that, because you did not do it the proper way."
• "You are borrowing credibility from smarter people."

Positive intent:

• push toward fundamentals
• reduce sloppy thinking
• keep you humble
• prevent arrogance (a genuinely useful feature)

Failure mode:

• credential worship
• ignores evidence of real work
• creates permanent "almost ready" projects
• makes you minimize your contribution in public

Multi-agent analogy:
The Gatekeeper is a schema validator with overly strict rules. It rejects valid outputs because the formatting is not what it expects.

How I use it now:

• I give it a narrow window. "Tell me the 2 fundamentals I should review this week." Then it stops.
• I do not let it veto shipping. It can suggest improvements, not block release.

Agent 3: The Late Bloomer

This one is memory-heavy. It stores the narrative of being behind, slower, or "not built for this."

What it says:

• "Everyone else learned this at 18."
• "You are late."
• "You always struggle."
• "This is the part where you fail again."
• "You are compensating, not belonging."

Positive intent:

• prevent repeating old pain
• encourage preparation
• avoid risky environments

Failure mode:

• turns growth into proof of defect
• makes learning feel shameful
• blocks new identities
• makes you compare timelines instead of outputs

Multi-agent analogy:
This is a retrieval system with a biased dataset. It over-indexes on negative examples because those were emotionally salient.

The engineering fix is the same as in AI retrieval:

• update the dataset
• add positive examples
• weight by recency, not trauma intensity

Agent 4: The Reality Doubter

I have a deep respect for how easily brains can lie. That respect is partly philosophical, partly earned. When your perception has been altered, you never fully forget that "what feels true" is not the same as "what is true."

What it says:

• "Are you sure you understand what is happening?"
• "What if your confidence is just mood?"
• "What if this is another story you invented?"
• "What if you are wrong and do not know it yet?"

Positive intent:

• prevent delusion
• keep calibration and humility
• encourage grounding
• reduce overconfidence

Failure mode:

• paralysis by doubt
• loss of momentum
• over-checking basic decisions
• turning normal uncertainty into existential uncertainty

Multi-agent analogy:
A safety agent that is valuable, but must not run as the orchestrator.

How I use it:

• it gets one question and one answer
• the answer must include an observable check, not an opinion _Example: "What evidence would change my mind?" If no evidence exists, it is probably fear wearing a lab coat.

Agent 5: The Veteran Body

This agent is not emotional. It is physical. It reminds me that energy is the actual currency of life.

What it says:

• "You cannot brute force everything."
• "Sleep is not optional."
• "Your future self is not a free compute cluster."
• "You are not 25. That is fine. Stop pretending."
• "Your body will invoice you later."

Positive intent:

• sustainability
• pacing
• protecting family life and long-term work

Failure mode:

• cynicism
• "too late" narratives
• avoidance of ambition

Multi-agent analogy:
Rate limiting and resource budgeting. In agentic systems, if you do not budget tokens and latency, you collapse. Same for humans.
A dry truth: when I ignore this agent, the Auditor gets louder. Fatigue is the Auditor's favorite amplifier.

Agent 6: The Builder

This is the agent I trust most, because it produces artifacts. It does not argue. It ships.

What it says:

• "Show me the smallest test."
• "Make the demo."
• "Commit something."
• "If it is real, it leaves traces."
• "Stop narrating and run the thing."

Positive intent:

• convert anxiety into evidence
• create momentum
• make reality measurable

Failure mode:

• overwork
• compulsive building to avoid feeling
• treating productivity as self-worth
• building systems as emotional regulation (effective, but expensive)

Multi-agent analogy:
The executor agent. The one that calls tools and changes the world. It needs a critic, but it needs autonomy too.
This is why shipping is a mental health intervention for me. It is evidence. Evidence is the only language the Auditor respects.

Agent 7: The Proof Archivist

This agent keeps the record. It is the antidote to impostor syndrome because impostor syndrome is amnesiac on purpose.

What it says:

• "Here is what you already shipped."
• "Here is the benchmark."
• "Here is the deployment."
• "Here is the code review where a strong engineer agreed."
• "Here is the message where you helped someone."

Positive intent:

• restore memory
• prevent catastrophic reframing
• stabilize identity with evidence

Failure mode:

• nostalgia
• hiding in the past instead of facing current uncertainty

Multi-agent analogy:
Memory plus observability. Without traces, you cannot debug. Without receipts, you cannot self-trust.
This is the same reason production systems need replay. The present is noisy. Replay is clarity.

---

How the agents interact

When I am regulated and functional, my system behaves like this:

1) A trigger happens (visibility, risk, criticism, big new goal).
2) The Auditor runs briefly and outputs bounded risk notes.
3) The Gatekeeper validates fundamentals, but cannot veto.
4) The Builder converts one risk into one concrete action.
5) The Archivist pulls existing evidence so the system does not reset to zero.
6) The Veteran Body sets a timebox and a stop condition.
7) The Reality Doubter does a quick calibration check, then exits.

When I am not regulated, the workflow looks like this:
1) Trigger.
2) Auditor loops.
3) Everything else becomes a servant of the loop.
4) I "prepare" for a future that does not exist.
5) I exhaust the system.
6) Exhaustion becomes proof.
7) Shame becomes the only output.

That is not a character flaw. It is a routing bug.

A day in the life of the workflow

To make this less abstract, here is a normal day where the system either works or collapses.

Morning: I open my laptop and see a message about a meeting.
The sign stimulus hits. The Auditor wakes up and opens a spreadsheet in my chest. The Late Bloomer contributes a helpful comment like "this is where you fail again." The Builder wants to respond by building something immediately, because building is my safest language.

If I let the system run uncontrolled, the day becomes:

• I over-prepare for the meeting.
• I ignore my actual task list.
• I do not ship anything.
• I end the day tired and ashamed, with a beautiful folder structure.

If I run the workflow, the day becomes:

• Veteran Body sets a 20 minute preparation limit.
• Auditor gets 5 minutes and must produce 3 risks with mitigations.
• Builder chooses one mitigation and produces one artifact.
• Archivist pulls one piece of evidence from past work so my brain does not start from zero.
• Reality Doubter asks one calibration question: "What would success look like in one sentence?"

Then I go to the meeting.
The outcome is not perfect. It does not have to be. It is stable.

After the meeting, the Archivist runs again for 2 minutes.
It writes: what went well, what did not, what was learned, what is next.
Not a diary. A changelog.

Evening: the Veteran Body insists on stopping.
This is the hardest part for builders. We love infinite loops. But if you do not stop, tomorrow is garbage. A good orchestrator can end a run without killing the project.

A minimal YAML for the brain

If you are a technical person, you may find it useful to think in a declarative flow. This is not code you should run. It is a way to see the structure.

orchestrator:
  id: marco_core
  strategy: selective_activation
  agents:
    - id: auditor
      runs_when: ["high_visibility", "high_risk"]
      budget: {minutes: 5, max_items: 5}
    - id: gatekeeper
      runs_when: ["identity_threat"]
      budget: {minutes: 3, max_items: 2}
    - id: builder
      runs_when: ["always"]
      budget: {minutes: 60, deliverable: "artifact"}
    - id: archivist
      runs_when: ["auditor_spike", "post_ship"]
      budget: {minutes: 5, deliverable: "evidence"}
    - id: veteran_body
      runs_when: ["always"]
      budget: {minutes: 1, deliverable: "stop_condition"}
    - id: reality_doubter
      runs_when: ["perception_drift"]
      budget: {minutes: 2, deliverable: "one_check"}

The key line is selective_activation.You do not run all agents all the time. You route based on context.

---

Why this model resonates with ethology

Ethology is basically the study of orchestration in living systems.

An animal is not one motivation. It is multiple motivations negotiating. The environment is not background. It is an input signal that changes which subsystem wins.

In tech terms:

• context is the prompt
• internal state is hidden memory
• behavior is the output action
• reinforcement updates the policy over time

The part that matters: you cannot judge an animal's behavior without its context. And you cannot judge your own mental behavior without context either.

My impostor agent is louder when I am tired. It is quieter when I have shipped something recently. It is unbearable when the work is public and ambiguous. That is not a moral failure. That is state-dependent behavior selection.

Also, ethology gives you a mercy rule: many behaviors are adaptive in one environment and maladaptive in another. Impostor syndrome is adaptive if you live in a social environment where mistakes are punished harshly. It becomes maladaptive when you are in an environment where learning requires public experimentation.

In other words: the agent is not evil. The environment changed.

Reproducing this in a multi-agent AI workflow

If you want to implement this idea in actual software, the mapping is almost direct.

You need:

• a clear orchestrator that decides who runs when
• role separation (critic is not executor)
• timeouts and budgets (critics get limited tokens)
• a memory component that stores evidence and prior decisions
• observability (logs and traces you can replay)
• a stopping rule (or you will plan forever)

You also need a principle that most people ignore: not every agent should run on every request. Humans do selective activation. A deer does not run its "mating strategy" module while fleeing a predator. If your system runs every agent on every query, you built a committee that never shuts up.

This is where most multi-agent demos fail in production. They are cognitively unselective.

Brains are selective because they have to be. Compute is expensive.

Implementation notes

This is the part where the engineering and the psychology become the same thing.

1. Observability is emotional regulation. If you cannot see what happened, you will invent stories. Humans invent blame stories. Systems invent hallucinations. Traces are the antidote for both. Log what ran, what it saw, what it decided, and why.
2. Replay is self-trust. If a workflow cannot be replayed, you cannot debug it. If your personal decision making cannot be replayed, you cannot learn from it. This is why the Archivist matters. It is not sentimentality. It is reproducibility.
3. Evaluation must be explicit. If your only evaluation is "seems good," the Auditor will never accept the result. Give the system a score, a rubric, or at least a binary gate. Humans need this too. The Builder needs a definition of done. The Auditor needs a stop condition.
4. Do not run every agent. Selective activation is not optional. It is the difference between a useful team and a meeting that never ends. It is also the difference between a helpful inner voice and a spiral.
5. Put the critic behind an interface. A critic that can talk forever will. Force it to write issues in a structured format. Then route those issues elsewhere. In humans, the structure is a timer and a list of mitigations. In AI, the structure is a schema and a max token budget.

If you build multi-agent systems and you are surprised by chaos, do not take it personally. You just discovered that coordination is the product, not the agents.

How to timebox your critic

If your critic agent is unconstrained, it will dominate. Critics are good at finding flaws. That is their job. The flaw is that they can always find more flaws.

In engineering, you solve this with:

• budgets
• termination criteria
• required output schemas
• evaluation gates

In humans, you can do the exact same thing.

Here is the prompt I use internally, in plain language:
"Give me the top 3 risks. Each must include one mitigation. If you cannot propose a mitigation, the risk is not actionable and you may not include it."

That simple constraint changes the critic from a doomsayer to an engineer.

In AI, you do the same. You force your critic to output structured concerns, not poetic fear. And you do not allow it to request infinite follow-up.

A practical exercise

If you want a lighter, human version, do this:

Step 1: Name the voices you already have.
Not the poetic ones. The functional ones. The part that criticizes. The part that avoids. The part that builds. The part that remembers. The part that worries about social status.

Step 2: Give each one a job.
Write one sentence: "Your job is to..." This is the fastest way to stop a part from impersonating the CEO.

Step 3: Put limits on the ones that never stop.
Give your inner critic a timer. Literally. Five minutes. Then it must output a list of actionable risks and shut up.

Step 4: Add a Builder step.
One risk becomes one action. Not ten. Not a new life plan. One.

Step 5: Add an Archivist step.
Write down receipts. You do not need a journal. You need a changelog. Your brain is bad at remembering progress under stress.

Step 6: Decide the stop condition.
Finish when you have evidence, not when you have comfort. Comfort has no upper bound.

Step 7: Add a recovery routine.
Animals recover after threat. They shake, groom, rest. Humans skip that and call it discipline. Your nervous system is not impressed. Add a short cooldown. It makes the next day possible.

This is not about becoming fearless. It is about becoming debuggable.

What this changes at work

Impostor syndrome is not just personal. It leaks into systems.

When the Auditor runs unchecked inside a team, you see:

• overengineering as anxiety management
• reluctance to ship without perfection
• endless refactors
• fear of visibility
• blaming ambiguity instead of designing for it
• slow decision cycles because nobody wants to be wrong in public

When the Builder runs unchecked, you see:

• shipping without tests
• burning out the team
• confusing motion with progress
• "we will fix it later" becoming the roadmap

So a sane team workflow is the same as a sane brain workflow:

• critics with budgets
• builders with autonomy
• a clear orchestrator (tech lead, product lead, or a documented process)
• observability, so you can debug without blaming people
• explicit definitions of done, so the critic can stop

This is why I am obsessed with tracing and replay in agentic systems. It is also why I keep personal receipts. It is the same problem at two scales.

One more dry observation: teams do displacement behaviors too. A team under social threat will fight about naming conventions. It will propose rewrites. It will build frameworks. Sometimes frameworks are necessary. Sometimes they are just grooming behavior with TypeScript.

The fix is the same as for an individual: reduce threat, add clarity, and route energy into measurable outputs.

Why I built orchestration tooling at all

I am not building agent orchestration because it is trendy. I am building it because it solves the exact problem I have internally: specialized components are powerful, but only if the system can coordinate them without chaos.

That is what orchestration is: turning a messy swarm of capabilities into something that can ship reliably.

If you are building multi-agent systems and you keep hitting the same walls (replay, observability, routing, cost control), you are not failing. You are rediscovering why orchestration exists.

If you want a concrete place to start, my work in this direction is OrKA-reasoning: https://github.com/marcosomma/orka-reasoning

Closing

There is a quote I keep coming back to: the measure of intelligence is the ability to change.

My impostor syndrome hates that quote, because change implies uncertainty. The Auditor wants certainty. The Builder wants movement. The Veteran Body wants sustainability. The Archivist wants receipts. The Gatekeeper wants legitimacy. The Reality Doubter wants calibration. The Late Bloomer wants to not get hurt again.

None of them are evil. They are just agents with different utility functions.

My job is not to silence them. My job is to orchestrate them.

And if this article did nothing else, I hope it gives you permission to treat your own mind like a system that can be designed. Not perfectly. Not permanently. But iteratively, with logs, with retries, and with a little less shame.

Because if your brain is going to run twelve services in parallel, you might as well add observability.