MindshineMindshineCortex for Allvue v1.0.891

Hands-on evaluation

The clearest next step Allvue asked for: give a couple of their people hands-on access, both to evaluate internal use and to see where cortex fits in sellable products. This page proposes a structured evaluation rather than an open sandbox: three exercises, each proving one of the points the review questioned, with what the evaluator sees at each step.

Setup

Item What Allvue receives
An organisation on the platform An organisation on the development environment with two evaluator accounts as organisation administrators; sign-in by password, or by single sign-on once the issuer is configured for Allvue
A project An empty project paired with its own engine fork, and read access to a finished reference project so the evaluators can compare
An MCP access token Minted in Settings, so an evaluator can also drive the project from an IDE or a headless client
This documentation and the product documentation The pages here plus docs.cortex.mindshine.com

Exercise 1: build an agentic workflow against a sample API

What it proves: how tools, workflows and agents are represented, and that an agent's reach is bounded.

  1. Upload a short brief as a requirement source: a process with one human approval and one automated step that reads a sample API. Watch the requirements appear with their citations.
  2. Approve the build preview. One card is filed; the fleet builds the endpoint that reads the API, the workflow with its steps and the agent actor's manifest, and attaches evidence.
  3. Open the workflow canvas, start a run, act on the human step from My Work, and read the actor's output on the run.
  4. Open the Agents page: the actor's tools are exactly the endpoints its manifest names; try to add a tool that does not exist and watch the manifest be refused.

Exercise 2: create or modify a reusable tool

What it proves: an endpoint is one thing used three ways, and every change is versioned.

  1. File a change card: "the API tool must also return the record's owner".
  2. When the card completes, open the endpoint in the studio: read the version history and the diff.
  3. Call the endpoint as a tool from an MCP client with the access token, then open the application screen that uses it and the test that asserts on it. Same endpoint, three callers.
  4. Restore the previous version from the history and watch the test go red on the next run, then restore again.

Exercise 3: change a requirement, regenerate, test, inspect the code and history

What it proves: developer control, contract governance and delivery.

  1. Upload a change request as a new requirement-source version. Observe that the existing requirements are not regenerated; only the affected rows are reworked, as a delta.
  2. Before filing the card, add an http contract test on the existing API that asserts the current response shape.
  3. File the card. If the change breaks the contract, the card fails on that test and says so; otherwise it completes with evidence.
  4. Open the App Services page, edit one file of the service by hand, save and rebuild. Then file a second small card and confirm the hand edit survives.
  5. Export the project (Deployments, Download for local run, Customer archive). Open the archive: the app service's Dockerfile and tree, the compose file, the runbook, the tests. Start it with one compose command on a laptop and run the tests inside it.

What each exercise answers

Review question Exercise
What exactly gets deployed 3, step 5
How workflows invoke tools; how agents are represented 1
Whether cortex is required after deployment 3, step 5
Developer override and source of truth 3, step 4
API contract governance 3, steps 2 and 3
Isolation and tenancy 1, step 4, and the reference project's data policies

The architecture validation session

The evaluation runs alongside one working session with Allvue's architects, built around the questions rather than a demo: deployment architecture with a real export on screen; identity and security against Allvue's own OIDC setup, walking through Security and identity with the gaps named; developer control (generate, edit by hand, version, change again); API and version governance with a contract test turning red on purpose; multi-tenancy on the reference project's policies. The pages here are the pre-read.