Immersive Blogs
Publications about innovation and new functionality.
6 Skills, 46 Agents: What Happens When Your AI Assistant Actually Specializes
TL;DR. Most AI assistants are one big prompt pretending to be an expert. Tessa is 46 smaller agents grouped into 6 skills, each with its own job and its own limits. One of those skills exists only to attack Tessa's own answers before you ever see them.
Updated 2026-05-12: Added a new section, "What's the Point: 46 Agents, One Click," on how Mosey makes the 46 agents reachable in one click from inside the 3D environment, and why the red-team and engineering-team skills in particular are the moment Mosey earns his keep.
Ask most observability AI assistants a question and you're talking to one model, one prompt, one context window trying to be everything at once. Diagnosis, code review, risk, design decisions, security: all crammed into one thread that tries to be an expert at all of it.
That's not how expertise works. A security researcher thinks differently than a systems architect. A risk manager asks different questions than a code reviewer. Cram all those views into one prompt and you get a weak copy of each.
Tessa doesn't work that way. She's 46 specialist agents grouped into 6 skills, ported from the open-source Jerry framework. Each agent has its own knowledge, its own limits, its own tools, and its own way of working. Ask a question and the router matches what you want to the right specialist. You don't need to know agent names or skill names. You just ask.
Here's what's inside.
Skill 1: Problem Solving (9 Agents)
The generalist skill. When you need to understand something complex, this is what activates.
Nine agents cover each phase of thinking a problem through. A researcher gathers facts from web search and your codebase, and cites what it used. An analyst works root cause, weighs trade-offs, and sizes up risk. An architect writes formal Architecture Decision Records. A critic runs creator-critic-revision loops and scores the work on six quality measures. A validator checks constraints against evidence. A synthesizer pulls patterns out of many documents at once. A reviewer handles code, design, and security reviews. An investigator uses 5 Whys and Ishikawa diagrams to follow a chain of cause back to its start. A reporter pulls progress together across work streams.
These agents don't just answer questions. They follow a set method. The investigator doesn't guess at a root cause. It builds an Ishikawa diagram, sorts symptoms from causes, and follows the chain back to where it started. The architect doesn't just suggest a design. It writes a Nygard-format ADR: the options weighed, the trade-offs written down, the risks named.
This is the skill that picks up when you ask Tessa "why is checkout slow?" or "compare these two approaches" or "what's the root cause of this failure?"
Skill 2: Red Team (11 Agents)
Full MITRE ATT&CK kill chain coverage. This is the skill that most people don't expect to find inside an observability assistant.
Eleven agents cover the whole offensive chain: recon, vulnerability analysis, how to exploit, privilege escalation, lateral movement, persistence, data exfiltration, social engineering, C2 infrastructure, and reporting. Scoping through final report.
Here's what makes this responsible rather than reckless. The skill is scope-gated. An Engagement Lead agent has to set Rules of Engagement before any offensive agent runs. Three of them, for persistence, exfiltration, and social engineering, must be named in those rules on top of that. You cannot run an exfiltration test by accident. The chain of approval is not optional.
Why does an observability tool need a red team at all? Because the teams using APM tools now own security, not just uptime. SREs and platform engineers are expected to know their own attack surface. Tessa helps them work through it in order, using the same methods a professional pen tester would.
Skill 3: Engineering Team (10 Agents)
Security-first software development lifecycle, from architecture through post-deployment incident response.
Ten agents cover the full build workflow. A solution architect does threat modeling (STRIDE, DREAD, PASTA). A lead holds the standards and plans the work. Backend and frontend specialists cover server-side and client-side security. An infrastructure specialist hardens IaC and the supply chain (SLSA, SBOM). A DevSecOps engineer sets up SAST/DAST in the pipeline. A QA engineer plans the security testing. A security reviewer reads the code by hand and tags findings with CWE. A final reviewer is the gate before release. An incident responder covers monitoring and runbooks after the deploy.
This isn't a generic "review my code" assistant. The backend agent knows OWASP Top 10 and ASVS 5.0. The infrastructure agent knows CIS Benchmarks. The DevSecOps agent knows how to set up Semgrep, Gitleaks, and Stryker. Each one brings knowledge a general LLM does not carry in its default prompt.
Skill 4: NASA Systems Engineering (10 Agents)
This is the one that surprises people. Tessa runs NPR 7123.1D, the real NASA systems engineering standard. Not a cut-down version. Not "inspired by." The actual processes.
Ten agents cover the full SE lifecycle. Requirements engineering handles stakeholder needs, writing requirements, and managing them. Technical architecture covers logical decomposition, design solutions, and decision analysis. Verification and validation covers test, analysis, inspection, and demonstration. System integration handles interfaces and ICD compliance. Risk management follows NPR 8000.4C with 5x5 likelihood and consequence matrices. Configuration management holds baselines and tracks change. Technical review gates run SRR, PDR, CDR and FRR with entrance and exit criteria. Exploration opens up the trade space. Quality assurance checks work products against NPR standards. And SE status reporting covers all of it.
Why NASA SE in an observability tool? Because these platforms watch complex systems, and complex systems do better under strict process. Teams building mission-critical work in healthcare, finance, aerospace and energy need more than "move fast and break things." They need traceability matrices, verification evidence, and formal review gates. Tessa can run those.
Skill 5: Adversary (3 Agents)
Tessa's self-critique mechanism. This is the skill that reviews Tessa's own output.
Three agents form the quality pipeline. A selector maps the stakes of the job (C1 advisory up to C4 mission-critical) to the right line of attack. An executor runs those attacks on the work and files findings, each rated by severity. A scorer applies LLM-as-Judge scoring across six measures: completeness, correctness, clarity, consistency, depth, and actionability. It returns one weighted score and a verdict: PASS (0.90+), REVISE (0.70-0.89), or ESCALATE (below 0.70).
This is the quality gate. When Tessa writes a design decision, a risk write-up, or a security review, the adversary skill can attack it before you see it. The assistant reviews itself, finds the weak spots in its own reasoning, and then approves it, sends it back, or escalates it to a human.
Most AI assistants have no quality check inside them. They write an answer and hand it over with the same confidence every time, good or bad. Tessa can score her own work and tell you when she is unsure.
Skill 6: Prompt Engineering (3 Agents)
The meta-skill. This one helps you build better prompts for any AI system, not just Tessa.
A builder walks you through the five parts of a prompt: identity, task, context, constraints, and output format. A constraint generator picks the pattern and writes the constraint block, covering what is required, what is forbidden, where the edges are, and what good looks like. A scorer rates the prompt against seven tests: clarity, specificity, format, context, edge cases, persona, and testability. It tells you how to improve each one.
This exists because the prompt is the biggest lever on what the AI gives back, and almost nobody has been taught to write one well.
Built on the Jerry Framework
Tessa's skills come from the open-source Jerry framework (Apache-2.0), created by Adam Nowak. We adapted Jerry's skill and agent definitions to run natively in our .NET assistant library. Every ported skill carries a header citing the Jerry source path, version, and license.
Beyond Skills: What Else Tessa Can Do
The skill system is the most distinctive part of Tessa's architecture, but there's more under the hood.
Multimodal vision input. Paste a screenshot into Tessa and ask "what's wrong here?" She takes images as well as text, so you can show her a dashboard, an error screen, or a log and get an answer without describing it first. Works in the desktop app (Ctrl+V, drag-drop) and the 3D client (Ctrl+V).
DAG workflow orchestration. For long multi-step jobs, Tessa can chain agents into directed acyclic graphs. Those support branching, gate nodes for human approval, and checkpoints so a failed run can resume. A triage agent writes its output, a router node reads it and calls the job "critical" or "routine", and the flow branches from there. A gate node halts the run until a human approves it. If nobody does, it cancels; it never approves on its own.
Self-scoring quality gates. When a skill returns an answer, Tessa can score it across six measures: completeness, correctness, clarity, consistency, depth, and actionability. If it scores too low, she hands the critique back to the agent to try again, up to three times. That is the adversary skill at work. The AI reviews itself before you see anything.
Hat-based role switching. Tessa can wear a different "hat", such as researcher, security analyst, coder, architect, or reviewer. The hat shifts what she focuses on without changing who she is. Wearing the security hat nudges the router toward the red team and engineering skills. The hat sets the focus. The skills bring the specialists. The two stack cleanly.
Context preservation. Long conversations don't fall apart. Rather than cutting off old messages, Tessa summarizes them in the background and keeps the recent ones whole. The summary is rebuilt bit by bit, and rebuilt in full now and then so it does not drift. Secrets are scrubbed out before any summary is stored.
2,326 tests. The assistant library has over 2,300 passing tests across unit, integration, and build verification. The skill system alone has 39 dedicated tests, and the DAG workflow engine has 53.
How Routing Works (Without You Thinking About It)
You don't need to know that Tessa has 46 agents. You don't need to pick a skill. You just ask a question.
The routing system handles intent matching automatically. "Why is the payment service throwing 500 errors?" activates problem solving. "Review this code for security vulnerabilities" activates the engineering team. "What's the attack surface of this API?" activates the red team (after scope verification). "Create an ADR for this migration" activates the architect agent within problem solving.
The keyword router takes the first pass. If it is confident, the question goes straight to the matching skill. If it is not, the model takes a second pass and works out what you meant. Common questions route at once, and unclear ones still reach the right specialist.
All 46 agents run on the same GPT-5.4 model family, through tier routing. The skills bring the knowledge, the limits, and the shape of the work. The model brings the reasoning. Together they beat what one generic prompt can do.
What's the Point: 46 Agents, One Click
46 agents is a lot. Most of the value is in the ones you didn't know to ask for.
At 2pm on a Tuesday, when a service is misbehaving, you don't know that you should run an adversarial review on your own diagnosis. You don't know that your trace looks like a security incident if you stand at the right angle. You don't know that the architecture decision you're about to commit would benefit from a steelman pass and a pre-mortem before you push it. Most users won't go open a chat console and type "please apply the S-002 devil's advocate strategy and the S-004 pre-mortem strategy to this RCA." They will just ship.
This is what Mosey is for. Mosey is the friendly companion in our 3D environment who lives next to whatever you're looking at. Click him and a small menu opens with three buckets: Help, Quick Read, and Deep Analysis. The Deep Analysis bucket is where the 46 agents become a one-click experience.
- Standing in front of a trace? Deep Analysis offers Investigate with me (problem solving), Run a full RCA report (problem solving + adversary), and Audit my LLM spend (engineering team).
- Standing in front of a service? Deep Analysis offers Threat-model this service (engineering team, STRIDE), Audit auth (engineering team + red team), and Plan a security review (engineering team).
- Standing in front of your code workspace? Deep Analysis offers Draft an ADR (problem solving, architect), Compare approaches (problem solving, analyst), Find related ADRs (problem solving, synthesizer), and Audit a pattern across the codebase (engineering team).
The red-team and engineering-team skills, in particular, are why Mosey matters. Most observability assistants don't have a red team mode at all. The ones that do bury it three menus deep behind a security console. Mosey puts it on the same shelf as "explain this trace" and lets you reach for it without changing tools, changing tabs, or remembering anyone's name.
46 specialists, in other words, are only as useful as the moment you can summon them. Mosey is the summon. Tessa is the answer. The skills are the depth behind the answer. You don't have to assemble that stack yourself.
See It in Action
Watch Tessa diagnose a production error, trace it through distributed services, and generate a complete root cause analysis document in one conversation: From Error to Full RCA in One Conversation.
Or see the full 3D environment where Tessa operates: Introduction to DeepCube.
To try it yourself, start free and populate your grid with realistic telemetry:
go install github.com/ImmersiveFusion/snowglobe/cmd/snowglobe@latest
snowglobe -endpoint otlp.deepcube.ai:443 -headers "api-key=YOUR_KEY" -complexity light
Then ask Tessa anything. She'll route to the right specialist.
Start Free. Immersive. AI-guided. Full-stack observability. Enter the World of Your ApplicationĀ®.
Dan Kowalski
DeepCube lead. Writes the open-source tools underneath it, Snowglobe and Shoebox, both Apache-2.0 and OpenTelemetry-native.
About Immersive Fusion
Immersive Fusion (immersivefusion.com) is pioneering the next generation of observability by merging spatial computing and AI to make complex systems intuitive, interactive, and intelligent. As the creators of DeepCube, we deliver solutions that combine web, 3D, and AI technologies, empowering teams to visualize and troubleshoot their applications in entirely new ways. This approach enables rapid root-cause analysis, reduces downtime, and drives higher productivity, transforming observability from static dashboards into an immersive, intelligent experience. Learn more about or join Immersive Fusion on LinkedIn, Mastodon, Bluesky, X, YouTube, Facebook, Instagram, GitHub, Twitch, Discord.Press inquiries: press@immersivefusion.com.
The Better Way to Monitor and Manage Your Software
Streamlined Setup
Simple integration
Cloud-native and open source friendly
Rapid Root Cause Analysis
Intuitive tooling
Find answers in a single glance. Know the health of your application
AI Powered
AI Assistant by your side
Unlock the power of AI for assistance and resolution
Intuitive Solutions
Conventional and Immersive
Expert tools for every user:
DevOps, SRE, Infra, Education