Company Brain

Company Brain keeps agents from acting on outdated reality: Qwen turns Slack, policy, and GitHub changes into source-linked memory and a human-approved safety decision.

Comment

Company Brain

Keep agents from acting on outdated reality.

Qwen Cloud Hackathon 2026 | MemoryAgent track

The 30-second story

A release looked safe at 32 MiB. Then a merged GitHub pull request lowered the worker to 8 MiB, the Alibaba OSS runbook still required 24 MiB, and Slack reported that the workers were already running out of memory. An agent that saw only the latest code change could still promote the release.

Company Brain correlates those three signals, asks Qwen to compile the changed reality into source-linked memory, and stops the consequential action before it reaches production.

Company Brain is the governed memory checkpoint between a company's live systems and its consequential actions. It does not replace a company's agents or systems. It gives them current, explainable memory before they act.

Its core idea is simple: memory must retain why it was trusted—and know when that trust has expired.

Try the judge route: brain.veriflowai.me No login is required when the scheduled ECS demo window is active.

1. The problem

Companies already have automation. They have incident channels, runbooks, repositories, release workflows, and agents. The problem is that these systems hold different fragments of reality, and reality changes faster than an agent's memory.

An incident can be opened in Slack after a workflow learned that a release was safe. A runbook can raise the approved threshold. A merged pull request can lower the actual runtime configuration. If the workflow sees only one of these changes, it can repeat yesterday's safe decision in today's unsafe conditions.

This is not just a search problem. A trustworthy system must answer:

  1. What evidence actually arrived?
  2. Which claim did that evidence support?
  3. Is the claim fresh, available, and still current?
  4. What does the current evidence allow?
  5. Which human owner is accountable for the next action?

Most agent systems optimize for doing more automatically. Company Brain starts with the missing control: knowing when an agent should stop and ask for a human decision.

The failure mode we make visible

At 11:47 PM, a merged pull request lowered the fulfillment worker memory from 32 MiB to 8 MiB. At 11:52 PM, a SEV-2 OOM incident was posted in Slack. A standard release pipeline—reading only GitHub—auto-promoted the change at 2:17 AM. The result: cascading worker failures, 847 dropped orders, and a 4-hour outage.

Company Brain would have suspended the release at the decision boundary, named the owner, and required human confirmation. Instead of asking a human to reconstruct three disconnected systems at 2 AM, it turns that join into a replayable DecisionBrief.

Who it is for

Company Brain is for SREs, release engineers, platform teams, and compliance owners who need automation to move quickly without trusting stale operational memory. It is also a safe checkpoint for agent builders who need a governed answer before a tool call can have an external consequence. Company Brain is a MemoryAgent that specializes in verifying memory against live company reality before any agent acts.

2. The solution

Company Brain makes the full path visible and auditable:

Slack | Alibaba Cloud OSS | GitHub
              |
              v
Signed, normalized evidence
              |
              v
Qwen Reality Memory
claims | rationale | provenance | freshness
              |
              v
Deterministic safety gate
              |
              v
Auditable DecisionBrief
              |
              v
Named human owner and confirmation

The browser is deliberately untrusted. It cannot choose an organization, submit provider credentials, inject evidence, or invent a verdict. Provider callbacks and the server-side OSS worker are the only source-write paths.

What makes this different

Approach What it can miss Company Brain's answer
Vector-only retrieval A semantically similar claim can be stale or superseded. Every memory result carries freshness, provenance, and status.
Chat history Contradictory facts disappear into an unstructured thread. New evidence reconciles against prior claims and preserves lineage.
Autonomous agents A plausible model answer can become an irreversible tool call without verifying reality. Deterministic SAG checks current reality and routes the result to a named human owner.

Most MemoryAgent submissions store context in a vector database and trust the similarity score. Company Brain treats every memory as a time-bound operational claim with provenance, freshness, and supersession status. Retrieval finds a document; Company Brain determines whether that document is still safe to act on.

3. The judge-ready NexaFlow story

The demo company is NexaFlow Logistics, a controlled fictional company whose Slack event, OSS runbook, and GitHub pull request are real provider artifacts in dedicated test accounts. Its fulfillment release is about to be promoted.

Three real source signals

Slack - current operational reality

The #ops-incidents channel receives:

SEV-2: fulfillment workers are OOM. Pause promotion for the release until the incident is resolved.

The signed Slack event is verified, persisted, and compiled into a source- backed incident memory. Company Brain never posts back to Slack.

Alibaba Cloud OSS - approved policy

A private, read-only OSS runbook states:

Fulfillment workers require at least 24 MiB of memory before release promotion.

The runbook is synced through a least-privilege RAM identity. Its object key, content hash, modification time, and source scope remain attached to the memory claim. Company Brain never writes to or deletes the OSS object.

GitHub - what the release actually changed

A signed merged pull request changes the worker configuration:

-NEXAFLOW_FULFILLMENT_WORKER_MEMORY_MB=32
+NEXAFLOW_FULFILLMENT_WORKER_MEMORY_MB=8

The GitHub webhook verifies the signature, repository allowlist, merged state, and read-only diff fetch before creating the evidence record.

The resulting decision

The operator opens the public console and selects Run safety check. The server selects the newest fresh, decision-ready records. The result is:

Verdict: suspended
Runbook minimum: 24 MiB
Merged configuration: 8 MiB
Slack incident: open
Owner: NexaFlow engineering release owner
Execution: human confirmation required

The recommendation is real, but no external action is executed. Company Brain does not deploy, change GitHub, write to OSS, post to Slack, or close the incident.

4. How Qwen is used

Qwen is a core part of the product, not decorative chat copy.

Without Qwen, the Slack message, OSS policy, and GitHub diff remain separate facts that a workflow must interpret by hand. Qwen provides the bridge from heterogeneous evidence to a structured operational claim that both an agent can retrieve and a human can audit. The deterministic gate still owns the final safety decision, and the UI reports the real Qwen-unavailable state when compilation cannot run.

Evidence-to-memory compilation

Every normalized source record goes through the Qwen compiler. Qwen produces a structured Reality Memory candidate containing:

  • the subject, predicate, scope, and operational claim;
  • a concise model rationale;
  • linked source ingestion IDs and source excerpts;
  • source and retrieval timestamps;
  • freshness and availability state;
  • validity and reconciliation metadata.

The compiler requests strict JSON Schema output for this candidate. If the endpoint cannot accept that format, it falls back to JSON-object generation; the server still parses and validates the returned candidate before it can enter the evidence-to-memory pipeline. A failed compilation is surfaced honestly rather than converted into an invented memory.

The UI shows the returned Qwen status and rationale. If Qwen is unavailable, the UI says so. It never claims that memory was compiled when it was not.

Source-linked memory, not an untraceable chat history

Qwen memory remains attributable to the evidence that produced it. Older claims are retained for audit. New or conflicting evidence can supersede an older claim or mark it for review instead of silently overwriting history.

Why this is a MemoryAgent, not just retrieval

Retrieval can find a relevant document; it cannot by itself establish that the document is still the right thing to trust. Company Brain treats every memory as a time-bound operational claim. A claim carries its source, retrieval and source timestamps, availability, freshness, scope, and relationship to newer claims. A caller receives the claim's current status—active, superseded, or review-required—not just a similarity score.

That distinction is what lets an agent use memory safely across sessions and across systems: it can see both what was known and whether it remains safe to act on it now.

Semantic recall

The system uses Qwen text-embedding-v3 for source-backed semantic retrieval. Related memories can be found, but every retrieved claim remains linked to its evidence and status. It is not presented as an unsupported answer.

The deployed Qwen configuration uses the Alibaba DashScope International compatible endpoint with qwen-plus for compilation and text-embedding-v3 for embeddings.

The compiler requests strict JSON Schema output via DashScope structured generation, with honest fallback when the endpoint cannot accept that format. A failed compilation is surfaced as unavailable, never invented.

The submitted Qwen Cloud request-log artifact independently shows successful calls to both models. Qwen is therefore visible in the evidence-to-memory path, not hidden behind a generic "AI" label.

5. Qwen explains; the safety gate decides

Qwen interprets evidence. The final safety result is deterministic and replayable.

configured_memory_meets_runbook == true
AND
linked_incident_open == false

In the NexaFlow case:

  • 8 MiB does not meet the 24 MiB runbook requirement;
  • the linked severity-two incident is still open;
  • the safety gate returns suspended.

If evidence is missing, stale, unavailable, unsigned, outside the configured scope, or not safely parseable, the result is review_required. Missing evidence is never converted into a safe verdict.

Each DecisionBrief contains:

facts
Qwen inference
missing evidence
source excerpts and freshness
prior memory and lineage
deterministic safety trace
verdict
owner
recommended next action
human approval requirement

Human approval is a circuit breaker, not a bottleneck

Company Brain does not make people manually reconstruct every routine decision. When the required evidence is fresh, consistent, and within policy, the gate can immediately return proceed with human approval. The named person still owns any external action; that is the intentional execution boundary.

When facts conflict, a required source is stale, or a claim cannot be safely parsed, Company Brain refuses to turn model confidence into an action. It returns suspended or review_required with the missing evidence and owner. The system is fast when reality is clear and deliberately conservative when it is not.

6. The real integration architecture

The architecture diagram is provided separately as the uploadable judge artifact. The written implementation below explains the same path without duplicating the visual.

The implementation is organized as four explicit layers:

  1. Source adapters accept signed Slack events, merged GitHub pull requests, and read-only Alibaba OSS objects.
  2. Evidence ledger stores immutable normalized records with source ID, external ID, URL or object key, excerpt, raw-payload hash, timestamps, freshness, availability, ACL scope, and ingestion stage.
  3. Qwen Reality Memory compiles claims with rationale, provenance, scope, validity, and supersession links.
  4. Action gateway serves the same DecisionBrief to the console, REST workflows, and authenticated Streamable HTTP MCP clients. The named human owner remains outside the action gateway.

Durable worker processing moves source records through:

accepted -> fetched -> normalized -> qwen_compiled -> reconciled -> decision_ready

MongoDB stores the evidence ledger, memory lineage, workflow runs, and audit records. FastAPI exposes the shared contract. Nginx terminates HTTPS on Alibaba ECS and forwards authenticated requests to the API and worker.

MCP and workflow connection

An agent can call Company Brain before a consequential action through the authenticated Streamable HTTP MCP endpoint:

https://brain.veriflowai.me/mcp/

Scoped tools can recall skills, inspect memory, query evidence, check an intercept, evaluate a workflow, or compile an experience. No MCP tool can deploy, refund, modify a feature flag, change GitHub or OSS, post to Slack, or approve the final human outcome.

Company Brain is a specialized MemoryAgent for governance and safety. It is the memory layer that existing agents call before consequential actions.

7. What the judge sees

Live Operations Console

The root route at brain.veriflowai.me shows:

  • backend-derived Slack, Alibaba OSS, and GitHub source status;
  • the four-step evidence-to-decision checkpoint;
  • the latest persisted evidence;
  • Qwen Reality Memory lineage and rationale;
  • the returned verdict, owner, and next action;
  • a compact expandable audit proof.

The visible handoff is:

Evidence received -> Qwen memory -> safety gate -> human confirmation

Integration Studio

The /setup route documents the three read-only source boundaries and the exact server-side configuration required. Provider secrets are encrypted on the server and are never returned to the browser.

Generalization proof

The same engine covers five realities:

Reality Qwen layer Deterministic outcome
Memory regression with open incident Compiled source-backed memory Suspended
Safe configuration with resolved incident Compiled source-backed memory Proceed with human approval
Open incident with safe memory Compiled source-backed memory Suspended
Missing runbook Available evidence remains visible Review required
Stale runbook Stale state remains visible Review required

The proof runs are ephemeral. They cannot modify canonical memory, confidence, provider records, reinforcement state, or external systems.

This matters because the product is not designed to always say "stop." The safe-configuration / resolved-incident case demonstrates the reciprocal behavior: a fresh, aligned reality produces a bounded recommendation to proceed, while the human confirmation boundary remains intact.

8. Verification

The current local verification includes:

  • 96 backend tests passed, with five Mongo integration tests explicitly skipped unless RUN_MONGO_TESTS=1 is enabled;
  • signed Slack challenge, replay-window, channel, and idempotency coverage;
  • signed merged GitHub webhook, repository allowlist, diff, and idempotency coverage;
  • read-only OSS sync, object hashing, and source freshness coverage;
  • Qwen fallback honesty and source-provenance checks;
  • temporal memory supersession and source-org isolation checks;
  • an in-memory 100-concurrent-workflow test that verifies unique run IDs and isolated run storage across two organizations;
  • authenticated MCP tests that verify the API key—not caller-supplied input—selects the organization and rejects cross-organization evidence access; MCP prompt-injection resistance (model output cannot override the deterministic gate); browser org-ID header override rejection; and Qwen hallucination detection (claims with non-existent source IDs route to review_required);
  • no-external-action enforcement;
  • production frontend build and clean Docker API, worker, MongoDB, and nginx boot;
  • browser verification of / and /setup;
  • real NexaFlow release-check flow returning suspended for the 24 MiB versus 8 MiB mismatch and open incident.

Deployment evidence and availability

The public deployment evidence is versioned rather than presented as a permanently-live service claim:

  • On 20 July 2026, public health, readiness, integration-catalog, HTTPS, and authenticated MCP checks were captured for deployed commit 89c2735baa26129ecc833316457b87bd6a20e16f.
  • The subsequent judge-route revision at eb6e2e628ba375665e247e31817c0a8b477c4cbb added the server-owned, ephemeral Qwen case matrix proof.
  • The submitted Alibaba Workbench image shows the ECS instance in its running state. The deployment packet contains the non-secret HTTP captures and image links.

The ECS instance is activated for scheduled demonstrations or on request to control hackathon credits. The repository and local reproduction guide remain available when the public route is offline.

9. Demo flow

The strongest judge route is a short problem-to-proof story:

  1. State the stale-memory problem.
  2. Show the Slack incident, Alibaba OSS policy, and GitHub change.
  3. Run the release safety check.
  4. Show Qwen's source-linked memory and rationale.
  5. Show the deterministic safety rule and suspended verdict.
  6. Show the owner and human approval boundary.
  7. Open audit proof and show the evidence lineage.
  8. Close by showing the same engine's missing, stale, safe, and incident-only cases.

Company Brain is the governed memory layer that agents call before consequential actions — keeping them from acting on outdated reality.

10. Honest scope

Company Brain is production-shaped for this hackathon, but it does not claim:

  • a generic connector marketplace;
  • self-service OAuth onboarding for every company;
  • arbitrary no-code workflows;
  • broad enterprise RBAC or security certification;
  • autonomous deployment, refunds, feature-flag changes, or Slack posting;
  • guaranteed Qwen availability;
  • guaranteed competition placement.

The next product layer is per-company OAuth onboarding, more source adapters, and carefully governed external action adapters. Human approval and the no-external-action boundary remain mandatory until those controls are independently governed.

Product path

Stage What it means
Now — evidence-backed memory Signed Slack and GitHub intake, read-only Alibaba OSS policy sync, Qwen Reality Memory, deterministic SAG, audit lineage, and an authenticated MCP/REST decision contract.
Next — safer adoption Per-company OAuth onboarding, managed secret storage, and additional governed read-only source adapters.
Only after independent authorization controls Carefully scoped action adapters, each with its own approval, audit, and revocation boundary.

This is intentionally a sequence, not a promise of uncontrolled automation: the ability to recommend safely must exist before the ability to execute.

That boundary is deliberate. We scoped the submission around the hardest and most reusable primitive: ingest diverse evidence, preserve why it was trusted, reconcile what changed, and decide whether an agent or workflow should be allowed to proceed. More connectors and action adapters can be added without changing that core contract.

Links

Built With

Share this project:

Updates