Agents, context, and MCP—explained simply
A plain-language guide to how Hyperoru turns technical evidence into a secure, living source of architectural truth.
Product concept · Plain-language guide
The simple idea
Hyperoru is a team of AI specialists that studies evidence from code, cloud, CI/CD, uploads, and approved tools. It builds a living model of what a system really is, explains how it knows, and helps people secure it.
Think of a software system as a city
- Repositories are the buildings.
- APIs and queues are the roads.
- Databases are the warehouses.
- Cloud permissions are the keys.
- CI/CD pipelines are the construction crews.
- Security weaknesses are broken locks or unsafe roads.
A normal scanner finds individual problems. Hyperoru should understand the whole city: what exists, how it connects, where trust changes, what is exposed, and what would be affected by a compromise.
The map is the interface. The trustworthy model underneath it is the product.
Four parts working together
| Part | Simple meaning | Job |
|---|---|---|
| Collectors | The eyes and ears | Gather facts from code, cloud, CI/CD, uploads, scanners, and MCP clients. |
| Context engine | The organized notebook | Give each specialist the smallest complete set of facts needed for its task. |
| Agents | The specialist team | Review evidence, security, architecture, threats, diagrams, and remediation. |
| Architectural truth | The verified case file | Store entities, relationships, proof, confidence, contradictions, and history. |
Architectural truth is more than a diagram
A diagram is only a view. The source of truth is a versioned model stored independently from the LLM and the visualization.
The model uses a few canonical building blocks:
- Entity: a service, repository, API, database, queue, cloud resource, pipeline, identity, team, or trust boundary.
- Relationship: calls, reads, writes, deploys, owns, contains, exposes, authenticates, or depends on.
- Evidence: the exact reason Hyperoru believes an entity or relationship exists.
- Observation: a fact seen at a particular commit, source version, and time.
- Confidence: how strongly the available evidence supports a claim.
- Contradiction: two evidence sources disagree.
- Supersession: a newer observation replaces an older one without deleting history.
For example, Hyperoru should not merely draw Checkout API → Orders Database. It should also know that source code contains the database client, cloud policy permits the connection, and the deployment configuration supplies the endpoint.
The trust rule
An agent may explain a claim, but it cannot turn an unsupported guess into architectural truth. Important claims must resolve to evidence from the same workspace and audit.
The context engine
Sending an entire repository and every historical observation to every model would be slow, expensive, and confusing. The context engine builds a bounded Context Pack for one specialist task.
A Context Pack contains:
- the audit goal and allowed scope;
- relevant entities, relationships, and evidence IDs;
- active findings, contradictions, and coverage gaps;
- architecture facts and trust boundaries;
- applicable workspace policies and accepted risks;
- repository, commit, scanner, model, and agent versions;
- token and cost limits.
Context and caches are always tenant-scoped. Repository text is treated as untrusted data, secrets are masked, and a changed source, context, agent version, model, or schema creates a new result instead of silently reusing an old conclusion.
The multi-agent team
One giant agent is difficult to test and easy to confuse. Hyperoru gives each role a narrow responsibility and makes them exchange typed artifacts rather than hidden reasoning.
scope + stage decisions
bounded evidence packs
citation + contradiction checks
technical findings
boundaries + structural risk
canonical result
The core roles are:
- Audit Coordinator plans stages, retries, budgets, and partial results.
- Context Curator prepares evidence-complete Context Packs.
- Evidence Verifier rejects claims that cannot resolve their evidence.
- Security Engineer analyzes vulnerabilities and practical exploit paths.
- Security Architect reasons about boundaries, exposure, coupling, and blast radius.
- Cloud/IaC Analyst understands infrastructure and access relationships.
- CI/CD Analyst maps build, identity, artifact, and deployment paths.
- Threat Modeler joins facts into abuse cases and attack paths.
- Diagram Architect produces safe views of verified entities and edges.
- Remediation Engineer proposes narrow, reviewable changes.
- Report Adjudicator resolves conflicts and produces the final structured report.
Every agent artifact records its agent version, context hash, model, evidence IDs, confidence, uncertainty, token usage, latency, cost, and decision summary. If proof is insufficient, the output becomes a hypothesis or coverage gap—not a confirmed finding.
MCP is the secure reception desk
MCP gives approved external systems a standard way to submit architectural evidence.
Other tools can drop off labelled evidence. They do not receive the keys to the building.
Useful evidence can come from cloud inventory jobs, CI/CD systems, OpenTelemetry processors, service catalogues, internal developer tools, or customer-built collectors.
Hyperoru keeps the MCP surface intentionally small:
- submit evidence batch
- create artifact upload
- complete artifact upload
- get ingestion status
MCP submissions are tenant-bound, size-limited, rate-limited, idempotent, and replay-protected. Raw artifacts are scanned and validated before normalization. Submitted content is never executed or passed directly to an agent.
How one audit moves through the system
The user can watch queue position, scanner coverage, active agents, cache hits, retries, cost, and graph changes. If one scanner or model fails, the audit remains useful but clearly reports a coverage gap. It never turns missing evidence into a clean verdict.
Why architecture changes security priorities
A scanner might say:
A vulnerable dependency exists.
Hyperoru should explain:
The vulnerable library is used by the public Checkout API. That service can reach the Orders Database across an internet trust boundary. Code and cloud evidence support the path, so compromise could expose order records.
That is structural security reasoning. It helps reveal:
- public services with unexpected database access;
- dangerous trust-boundary crossings;
- shared identities that increase blast radius;
- CI/CD paths with excessive deployment power;
- hidden dependencies missing from documentation;
- weak isolation between sensitive services;
- architecture drift between expected and observed reality;
- findings that become urgent because of reachability and consequence.
A living source-of-truth loop
Raw evidence is not the source of truth. An LLM response is not the source of truth. A Mermaid diagram is not the source of truth. The canonical, versioned, evidence-backed model is the source of truth.
What Hyperoru should own
Open-source scanners and collectors can remain sensors. Hyperoru's differentiating layers are:
- the architecture ontology;
- cross-source reconciliation;
- evidence-backed architectural truth;
- confidence and contradiction handling;
- temporal architecture history;
- structural security reasoning;
- context selection and compression;
- organization-specific intent;
- future change-consequence analysis.
The product promise
Connect your system
Hyperoru shows what exists, how it connects, how it knows, where the structure is weak, and what to fix first.
A trustworthy result lets a customer say:
- “Yes, these are our real services.”
- “Yes, those connections are correct.”
- “I can inspect the proof behind every important edge.”
- “I understand what is missing or uncertain.”
- “I can see how the system changed.”
- “The risks are prioritized using architecture, not severity alone.”
Continue with architectural truth, the context engine, the multi-agent workflow, or the MCP evidence gateway.