Armakuni Contact us
← All case studies

The editor could do anything.
Customers left because they couldn't use it.

A visitor-management software company's workflow editor was so flexible it needed nested JSON to change, and customers were churning rather than learning it. Its leaders wanted a three-to-five-year AI roadmap done in twelve months. We started with an editor where administrators describe the registration flow they want in plain English and review what the AI builds. It went from a four-to-five-week proof of concept to production, then to one identity for visitors across six acquired products. AWS funded every stage.

Before

Flexibility nobody could reach.

Six products, six ways to store a visitor.

After
Hourssaved per workflow, in the company's own testing
10+node types in the production editor

Flexibility nobody could reach

The company's platform could run complex visitor registration flows: identity checks, signatures, host selection, routing, watchlist screening. Using that flexibility meant editing nested JSON and clicking into every node by hand, often with an engineer's help. For a larger flow, one change could mean opening dozens of nodes.

That cost the business at both ends. Existing customers struggled to change their workflows, and some left rather than learn. Sales teams needed engineers to demonstrate configurations to prospects, so the product couldn't sell itself.

Six products, six ways to store a visitor

The company had also grown by acquisition: six applications, each with its own identity schema. One called it DOB, another birthdate, another date_of_birth. A visitor who registered at one site had to type the same details again at the next, and there was no platform-level control over what a visitor's information could be shared with.

Describe it, then review it

We kept the product's power and changed how people reach it: an administrator describes the registration process in plain English, the AI produces the configuration in the product's own structure, and the administrator reviews it in the editor they already have, without hand-writing any JSON.

How we built it

4 decisions, in the order we made them. Each one says what we did and why, with what it did drawn beside it.

  1. Generate the product's own JSON, from its own templates
  2. Production: more node types, and the editor enforces the rules
  3. One visitor, six schemas, and the visitor decides what's shared
  4. From an AI agent that answers to one that watches

Generate the product's own JSON, from its own templates

Built withBedrock
The admin says what they wantThe AI agent builds from templatesThe product's own JSON
The engineering

The proof of concept used a model on Amazon Bedrock to turn the plain-English request into JSON with nodes, branches, parameters and UUIDs, starting with branch, form, camera and video nodes. The company's predefined node templates were shared with the AI as its reference, so every generated workflow matched the platform's established configuration patterns.

It met all four of its success criteria: it mirrored sample workflows with valid JSON, generated valid JSON for new workflows from a prompt, modified existing flows while keeping the structure valid, and handled branch nodes consistently. The proof of concept took four to five weeks, fully funded by AWS, and the company's own testing found it saved administrators hours per workflow. An AI that writes into the product's own schema can be checked by the product's own editor.

Production: more node types, and the editor enforces the rules

Built withFastAPIPostgreSQL
A generated workflowRequired fields checkedTier permissionsVersions and rollbackA sandbox before live
The engineering

The production build expanded coverage to more than ten node types, including identity, signature, host selection, routing, HTML and watchlist checks. Generated configuration has to pass the product's existing structural and access rules, and the model can't skip them:

  • The output uses the application's workflow structure, so it can be reviewed and adjusted in the editor.
  • Missing required fields produce a warning on the affected node and a request for the administrator to supply the information.
  • Account-tier permissions control which node types an account can use, enforced in the FastAPI backend.
  • PostgreSQL stores workflow versions and change history, and rollback lets an administrator restore an earlier configuration.
  • A sandboxed testing environment keeps AI-generated workflows away from live systems until they've been checked.
  • Secure endpoints, encryption at rest and in transit, AI-interaction logs for audit and observability come with the production build.

Administrators review a generated configuration instead of building each node by hand.

Why: the permission check lives in the backend, so a prompt can't talk the AI into a node type the customer hasn't paid for.

One visitor, six schemas, and the visitor decides what's shared

Built withBedrockDynamoDBReactFastAPICognitoRDS
Schema 1Schema 2… six One identity the visitor chooses what's shared
The engineering

We addressed identity as a separate proof of concept. Bedrock maps equivalent fields, standardizes formats and flags inconsistencies, producing one normalized JSON record across the six schemas. Reusing the profile depends on the visitor's choices:

  • An opted-in profile is stored in DynamoDB under one unified identity.
  • A later registration retrieves the profile and prepopulates the permitted fields.
  • A consent screen lets the visitor choose which attributes an organization may receive.
  • Consent is timestamped, and the retrieval APIs enforce the selection by withholding excluded fields.
  • Profile updates flow back to the central record for the next visit.

API-enforced consent decides which fields can be shared, independently of the model-assisted field mapping. The prototype used React, FastAPI, Cognito, DynamoDB, RDS PostgreSQL and Bedrock, with Nova, Claude and Titan among the model options. Federation and risk features are on its roadmap.

From an AI agent that answers to one that watches

Built withBedrock
next stepOfficial pagesFeeds and APIsA rule changes Admin
The engineering

The company already ran an internal AI agent on Bedrock, connected to its business systems, that staff used every day to answer questions. The next requirement was for it to monitor relevant regulatory sources and bring changes to people's attention. We assessed the sources and designed the extension:

  • Source assessment checked the available pages, official feeds and APIs before recommending how to collect from each.
  • Bedrock would summarize each change in the context of visitor-management workflows.
  • Normalized records would support later questions and alerts through the existing AI agent.

The deliverable was an architecture and an implementation roadmap. The monitoring build is the next step.

One workflow, end to end

  1. For example, an administrator types: "Visitors sign the NDA, then pick their host. Contractors also need a watchlist check."
  2. Bedrock generates the workflow JSON from the company's node templates: a signature node, a host-select node, a branch for contractors and a watchlist node.
  3. The backend checks the account's tier, and allows the watchlist node only if the account has it.
  4. A required field is missing, so the editor flags the node and asks the administrator for it.
  5. The administrator adjusts one step in the editor and saves. PostgreSQL stores the new version.
  6. A week later, they roll back a change they didn't like, in one step.

What we'd tell another CTO

1Keep the product's power and change the way in. A plain-English layer over the existing editor kept every node type the customers relied on, where a simpler product would have taken them away.
2Version every generated configuration. Rollback is what makes administrators willing to try the AI on a live registration flow.

What else changed

  • A production AI workflow editor covering more than ten node types, with tier permissions, missing-field warnings, version history, rollback and an audit log of AI interactions.
  • One visitor identity across six acquired products, as a proof of concept, with consent the visitor controls and the API enforces.
  • An architecture and roadmap for an AI agent that monitors regulation.
  • Four pieces of work in 16 months, each one AWS-funded, so the company hasn't paid us directly for any of them.

What comes next

Federation and risk scoring on the identity layer, watchlist integration, identity across organizations, and the compliance-monitoring AI agent built.

How we'd do it today

This project came before our current offers. Here's how we'd approach the same work now.

With AK AI Factory, every node type would have a test: a golden set of real customer workflows and the configurations that should come out, plus a sealed set, with a dropped watchlist check treated as a critical case. The regulatory-monitoring AI agent reads untrusted pages and feeds, so it would follow the rule that no AI agent holds private data, reads untrusted text and can send data out at once, with its own identity in AgentCore Identity and Cedar policies at the gateway, checked on every tool call. To run and improve it, a new prompt or model would go to a small share of administrators first and roll back on its own if quality crosses a line agreed in advance.

Modernize with AI AK AI Factory

More work like this

  1. AIPlain EnglishA U.S. concussion-management platformquestions answered across both clinical modules, in the proof of valueA return-to-play decision shouldn't wait for someone who knows SQL.$1,300 net cost to the customer4–5 weeks to the proof of valueOn AWS S3 · Bedrock · Fargate · RDS
  2. AIParallelA Canadian legal software companyreading of every bundle, so throughput is no longer capped by headcountA new law firm arrived with 400 pages. Someone had to read every one before it went live.5–6 weeks to a working prototype that reads onboarding bundles in parallel300–400 pages per bundleOn AWS Bedrock · S3 · ECS · Fargate
  3. AIFirstA U.S. drug testing networklabeled sensor dataset for this kind of testing, and a working prototypeCameras weren't allowed in the room. So we built a way to sense cheating without seeing anyone.24,000+ tests a day the pipeline is sized for120 testing centersOn AWS S3 · Lambda · DynamoDB · API Gateway

All case studies →

Have a problem like this one?

A free workshop: a few hours with the architects who'd do the work, on your own systems. No cost.

Book a free workshop