Agentick VT × Accenture Federal Services · Build Challenge
Menu
Run demo

Agentick

A supervised AI workflow workspace. Agents draft, people decide, and every approval is a signature over the content it approved.

Run the demo See how it works
127.0.0.1:4182/#/desk/run-9f3a DEMO WORKSPACE AGENTICK SERVICES Workspace Work items Workflows Team agents Reference documents ASSURANCE Release approvals Audit trail Readiness alex.writer · author WORK ITEM · DOC-001 How do I request repository access? Documentation request · revision 3 · owner alex.writer ✓Intake ✓Grounding ●Review ○Handoff AWAITING APPROVAL · 1 OF 2 EVIDENCE 1 source · 1 tool · 2 checks ●SOP.md §2 Repository accessread · 1,240 chars ●read_project_file1 call of 5 ●Every claim cites a sourcepassed ●No access was grantedpassed Sources named read, empty or missing. Missing fails the draft. ORIGINAL OUTPUT qwen2.5-coder:7b · 00:41 1. Obtain team owner approval. [SOP.md §2] 2. Response target is two business days after approval. [SOP.md §2] 3. Requests without approval are returned. [SOP.md §2] No access has been granted. hash 9f3a71c0…c2e1 · read only HANDOFF edited by alex.writer · 2 min ago Ask your team owner for approval in the access request form. Expect a reply within two business days. Unapproved requests come back to you. Source: SOP.md §2. No access is granted by this answer. Edit handoff any edit voids the signatures below APPROVAL 1 OF 2 ✓sam.reviewersigned 9f3a71c0…c2e1 ○jordan.reviewerwaiting —alex.writerowner, cannot sign Approve this handoff signs the content hash, not the page
Runs on your laptopLocal model or your providerData in one folderConnectors read onlyRules enforced on the server
01 / What it does

The tools to
trust the draft.

  1. 01

    Workflows

    Every run on one page: the stage it is on, who owns it, the state of its output and the one next action.

    Blocked, waiting and done look different at a glance. A run keeps its own frozen copy of the workflow it started with, so a template edit never changes work already in flight.

  2. 02

    Output review

    Evidence, original output, your edits and the approval state side by side.

    The evidence names each source as read, empty or missing, so a confident draft built on nothing is caught before anyone signs it.

  3. 03

    Approval gates

    Independent reviewers sign a hash of the content. The owner and the author can never approve their own stage.

    Change the content after signing and the signatures stop counting. The server enforces this, not the page, so any client that skips the interface meets the same rule.

  4. 04

    Agent Studio

    Build agents from honest templates, grant tools with call budgets and timeouts, and test them before they touch a stage.

    A saved test is bound to the agent version it was written for. An agent without a passing test on its current version cannot be assigned; the API answers 409.

  5. 05

    Connectors

    Attach a reviewed, hashed snapshot of a Jira ticket, a Confluence page or an Ontology dataset to a run.

    Evidence reads are read only and separate from configured actions such as a Jira update, a Slack message or a reviewed Lambda invocation. A public dataset enters through ontology:ingest with each source file's hash recorded.

  6. 06

    Audit package

    Any run exports as Markdown or JSON with every output, signer and hash, and verifies offline.

    corepack pnpm audit:verify file.json recomputes every hash and names each problem. A handling marking such as CUI appears on every page and on the first and last line of every package.

02 / Walkthrough

One request,
start to signed handoff.

An employee needs the repository access process. The agent must use the SOP, show its evidence, and wait for independent review. Scripted, synthetic, no network calls.

Illustrative walkthroughSynthetic SOP · scripted output · no network calls

Backend responsibility

Presenter notes

Five minute presentation route
  1. 30 seconds: describe the documentation request and why a chat answer alone is insufficient.
  2. 90 seconds: walk through the source, tool grant and draft. Separate execution success from answer quality.
  3. 60 seconds: try owner approval, simulate two independent reviewers, then revise the draft to show why it needs review again.
  4. 60 seconds: open Engineering and follow one request through the UI, API, engine and storage.
  5. 60 seconds: show the real workspace or explain the reproducible scripted demo; close with current limits.
03 / Evidence

Signatures,
in context.

A run's record as an auditor reads it. Every stage carries the hash of its output, who produced it and who signed it. The accent column is the one a reviewer is being asked to sign now.

StageOutput hashAuthorSigned byState
Intake4b1e9d…08a7alex.writerno gatecomplete
Groundingc07f2a…51d3docs agentsam.reviewer · jordan.reviewercomplete
Review9f3a71…c2e1alex.writersam.reviewer · 1 of 2awaiting approval
Handoff———pending

Sample values. In the application the hash is SHA-256 over the output text; the audit package carries the full digest and audit:verify recomputes it.

How a stage works

Five steps.
No shortcuts.

  1. 01

    Agent drafts

    Read only tools, a call budget, a timeout and the sources it must read.

  2. 02

    Evidence attached

    Files read, tools called, checks passed or failed, all named.

  3. 03

    Person reviews

    The draft sits beside its evidence. The owner edits the handoff.

  4. 04

    Reviewer signs

    Never the author, never the owner. The signature is over a content hash.

  5. 05

    Stage locks

    The run advances and the trail stays. Edit the output and the signatures are void.

04 / Engineering

One policy boundary.
Many ways to work.

The browser presents state. The server decides what may happen. MCP clients reach the same workspace engines through scoped tools.

Browser / MCPIdentity + schemaWorkflow engineEvidence + review
TypeScript / ESMNode 22React + HTML/CSSZodMCP SDKesbuildJSON persistence
Follow a real request through the code
  1. browser.ts renders the workspace and submits an action to the HTTP API.
  2. server.ts resolves identity, verifies workspace membership and validates the payload.
  3. pipeline.ts checks the run revision, stage, role and approval rules before updating state.
  4. scheduler.ts runs approved assistant stages with saved references. Local repository agents use bot-worker.ts with explicit tool policies.
  5. storage.ts persists workspace state. Drafts, evidence and content hashes remain available for review.
05 / Company security

The right access.
At every handoff.

Choose a company, assemble its agents into a workflow, then check the configuration before handoff. Select a stage to see the application control and its proposed AWS protection.

Company + teamTools + agentsWorkflow + controlsReview + readiness

Illustrative control walkthrough. No authentication, AWS request or security test runs here. AWS protections require deployment and validation; they are not active in this local preview.

Before a company goes live
  1. Review agent assignments, model choices, references, tool permissions and execution limits. Current workflow checks report blockers; they do not deploy infrastructure.
  2. Separate production and development accounts; scope operator, worker and deployment roles.
  3. Test tenant isolation, denied tools, provider destinations and independent approvals.
  4. Review vulnerabilities, rehearse incident containment and restore a workspace from backup.
  5. Agree on data retention, region and provider use. Cloud hosting alone does not establish compliance.
Read the security control map
Your data

One folder on disk.
That is the whole story.

No cloud by default
The app listens on your own machine only. Configured remote models and integrations receive the content you send to them, and nothing else.
Readable storage
Runs, approvals, agents and tests are plain documents in one workspace folder. Back it up, move it, open it.
Separate workspaces
Company identity and membership select access. A matching email domain alone never grants workspace authority.
Grows to a company server
The same product runs with sign in, tenants and independent reviewers when a team needs a shared instance.
Handling marking
One setting puts the agency's marking, for example CUI, on every page and into every audit package.
Federal readiness
Product behaviour mapped to NIST SP 800-53 control families, with the file and test behind each line. Read the map ↗
Federal Spaces / OpenFEMA

Try the Virginia briefing.

Run the Public Data Analyst, inspect its MCP tool calls and review its findings.

Run the browser demo →Run the full workflow locally ↗
06 / Questions

A few things
worth knowing.

Does it send my documents anywhere?

Model requests and configured external actions can send selected content outside the workspace. Review references, provider settings and message previews before sending. Nothing leaves the machine on its own.

Can an agent publish or deploy on its own?

No. Agents receive no deployment rights. Approval gates and integration permissions are checked by the backend, and configured external actions are separate from drafting.

Which models work?

Installed Ollama models and supported provider integrations with valid credentials. Saved connections use server side settings or the encrypted vault. Agent definitions reference credentials by setting name.

What happens when something is not set up?

You get the setup steps on the page. Not connected, not assigned, blocked and waiting each show the one action that resolves them.

Is this a compliance claim?

No. The federal readiness map shows which behaviours support which control families and names the known gaps. An authorization decision belongs to the agency and its assessors.

07 / Submission

What to inspect.
What remains.

Evidence you can reproduce

Latest local application verification: October 22, 2026. These results describe the working prototype, not hosted CI or a live provider accuracy benchmark.

777tests passed / 778 total
0failed · 1 skipped
✓typecheck + both builds
corepack pnpm typecheck
corepack pnpm test
corepack pnpm build
corepack pnpm build:workbench

Current limits

  • This website simulates the journey; it is not an authenticated workspace.
  • Model completion and token counts do not establish answer accuracy. Review the cited evidence.
  • Company repository execution needs isolated workers before it can be enabled.
  • File backed company storage assumes one writer. Hosted scale, backup and recovery need further work.
  • Clerk, Stripe, Slack, Jira, Lambda and Foundry require real configuration. This page connects none of them.
  • No claim of federal authorization, accreditation or production readiness.
Inspect submission source Engineering guide

Presentation source: docs/site/. Open index.html directly, or run node docs/site/serve.mjs for the local preview. All sample records on this page are synthetic.

Built for delivery teams. Open by design.

Connect a model,
run one workflow.

Run the scripted demo from source using the commands above. For a live model run, configure Ollama or a provider, inspect the evidence, and use independent reviewers. A public Windows download is not available yet.

Run the demo View on GitHub