Skip to main content

Walkthrough

This page plays one demo workflow through from start to finish — generating it from its agent skill, publishing it, running it, approving the request it raises, and confirming the result — without signing out once. You sign in as root and use impersonation to act as each demo account in turn, so the whole tour fits in one browser tab.

Pick a provider here. Every provider-specific block on this page follows the choice.

You will launch an EC2 instance from the Demo AWS EC2 Launch skill.

Before you start​

  • The backend is running with demo data enabled.
  • You know the root password — ROOT_PASSWORD, or the line the backend logged once at startup when it was left unset (Seeded users).
  • The provider can really be reached:

The demo-aws-credentials secret holds a real access key: either DEMO_AWS_ACCESS_KEY_ID / DEMO_AWS_SECRET_ACCESS_KEY were set before the first start, or you edit the secret under Secrets. The run launches a real EC2 instance, which costs money until you terminate it.

The key's IAM user needs a policy that lets it resolve the AMI, look up the network and key pair, and launch the instance. This is enough:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ResolveAmi",
      "Effect": "Allow",
      "Action": "ssm:GetParameter",
      "Resource": "arn:aws:ssm:*::parameter/aws/service/*"
    },
    {
      "Sid": "LookupAndLaunch",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeImages",
        "ec2:DescribeVpcs",
        "ec2:DescribeSubnets",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeKeyPairs",
        "ec2:DescribeInstances",
        "ec2:RunInstances",
        "ec2:CreateTags"
      ],
      "Resource": "*"
    }
  ]
}

The first statement reads only the public parameters AWS publishes the latest AMI ids under, not your account's own parameters. The policy does not let the key terminate the instance — do that yourself in the AWS console.

No account to spare? The seeded tool mocks let the same workflow play through without reaching a provider. That path runs the workflow while it is still a draft, so it skips the publish step below.

The cast​

StepAWSGoogle CloudAzureRole
Generate the workflowdemo-aws-developerdemo-gcp-developerdemo-azure-developerdeveloper
Publish itdemo-aws-reviewerdemo-gcp-reviewerdemo-azure-reviewerreviewer
Run it, and confirm the resultdemo-aws-requesterdemo-gcp-requesterdemo-azure-requesterrequester
Approve the requestdemo-approver-1demo-approver-1demo-approver-1approver

Every step below starts with Impersonate on the Users list and ends with Stop on the "Acting as" chip in the header. The stop is not optional: while you act as one of these accounts you are held to that account's roles, and none of them may impersonate, so Impersonate is not offered again until you have stopped. From a chat screen, the A2Flow logo in the app bar takes you back to the welcome page and its sidebar.

1. Sign in as root​

  1. On the sign-in page, enter root as the Username, leave Tenant blank — root is a platform administrator and belongs to no tenant — and enter the password. Press Sign in.
  2. You land on the welcome page. The tenant selector in the app bar reads Default, the tenant the demo data lives in. Pick it if something else is selected.

2. Act as the developer and generate the workflow​

  1. Open Users in the admin sidebar and press Impersonate on the developer's row. Confirm with Impersonate in the Impersonate User dialog. You are back on the welcome page, and the header chip reads "Acting as demo-…-developer".
  2. Open Agent Skills. Only this provider's skill is listed — the others are hidden by their access-control tags. Wait until its Status reads ready, refreshing the list while it still says Cloning; Generate workflow stays disabled until then.
AWS: read the price sheet first

Open Knowledge Bases and click AWS EC2 Pricing. Its one source, ec2-on-demand-pricing.pdf, reads Not read. Click Read and wait until its status reads Ready. The LLM is turning the price sheet into pages, which appear under Pages; it takes a minute or two (Knowledge Bases). In the next step, also click Select knowledge bases… in the Generate Workflow dialog and choose AWS EC2 Pricing, so the run's agent can look prices up.

  1. Press Generate workflow on the row. Leave Workflow Name as it is, paste the prompt below into Prompt, and press Generate.
Ask the requester for the parameters they want and the date and time to launch, get approval from the Demo Approvers group, then launch an EC2 instance at that time.
Have them choose the instance type from:
- t4g.nano
- t4g.micro
- t4g.small
- t4g.medium
- t3.micro
- t3a.micro
- c6g.medium
- m6g.medium
- t2.micro
- t4g.large

Have them choose the region from:
- us-east-1
- us-east-2
- us-west-2

For the AMI, use the latest Amazon Linux 2023 image in the requested region.
Use the default VPC, subnet, and security group.
Do not create a key pair.
Resolve the AMI, VPC, and subnet IDs before requesting approval.
Do not launch the instance before the requested time.
Answer questions about what an instance costs from the AWS EC2 Pricing knowledge base, and include the requested instance's monthly cost from it in the approval request.
  1. You land on the new workflow's detail page with the status generating. The page refreshes itself; in a minute or two the status becomes draft and the bell shows a "draft ready" notification. Open its Task Templates to see the steps the design agent wrote — gathering the parameters, asking for approval, doing the work, and reporting back (Generating a workflow).
  2. Press Stop on the "Acting as" chip.

3. Act as the reviewer and publish​

  1. On Users, press Impersonate on the reviewer's row and confirm.
  2. Open Workflows and click the workflow's name. Look over its task templates; a reviewer may also Open design session to read the design conversation, but not steer it.
  3. Press Publish. The status becomes published: the design is frozen, and a requester may now run it (Publishing).
  4. Stop.

4. Act as the requester and run it​

  1. On Users, press Impersonate on the requester's row and confirm.
  2. Open Workflows and press Run on the workflow. The Run Workflow dialog offers no mocks — the workflow is published, so this is a real request. Press Run.
  3. The workflow session opens and the agent starts on the first task, asking for what the prompt left to the requester. A question with a fixed set of answers is a choice inside the message; otherwise a row of suggested replies appears above the input.

Not sure which instance type to pick? Ask, for example "What does t4g.medium cost per month in us-east-2, compared with t3.micro?" The agent looks the prices up in the AWS EC2 Pricing knowledge base and names the page it used.

Choose an instance type from the ten in the prompt and a region from the three, give a launch time a few minutes from now so the tour does not stall, and answer whatever else it asks, such as a name for the instance. The agent then looks up the latest Amazon Linux 2023 image in that region and the default VPC and subnet, summarizes the configuration and the launch time, and sends it off for approval.

  1. The request is addressed to the Demo Approvers group, and under it the chat reads "Waiting for a decision from the approver group." — the requester cannot decide it. The run now waits.
  2. Stop.

5. Act as the approver and approve​

  1. On Users, press Impersonate on demo-approver-1 and confirm. demo-approver-2 would do just as well: the first decision settles a group request.
  2. The bell in the toolbar shows one unread notification, the approval request. Click it to open the run's chat. Approvals in the sidebar, then Open Workflow Session on the row, leads to the same place.
  3. Read the request. Below the agent's summary, This authorizes lists the calls the decision would permit and the bounds on their inputs (What a request authorizes):

The call on the AWS MCP Server that launches the instance. Check it, and the launch time and monthly cost in the summary, against what the requester chose — the image, VPC, and subnet look-ups are not listed, since they ran before the request and needed no approval.

  1. Want to know more before deciding? Type a question in the chat and send it. On the AWS tab, for example, ask "What would this instance cost per month if it ran only on weekdays during business hours?" The session is waiting for your decision, so a Consultation tab opens and the agent answers there, from the request's context and the linked knowledge bases (Consultations). The requester can join that conversation too. When you are done, click the Main tab to return to the request.
  2. Leave a Comment if you like and press Approve. The decision closes the consultation, if you opened one. The run resumes in the same chat and the agent does the work, then asks the requester to confirm the outcome. That question is the requester's to answer: for you the input is read-only, with "Waiting for the initiator to respond." beneath it.

If the launch time has not come yet, the agent leaves the launch waiting, says in one line when it will continue, and pauses. The session resumes on its own at that time — nobody needs to keep the chat open — and the agent launches the instance (The workflow session screen).

  1. Stop.

6. Back as the requester: confirm the result​

  1. On Users, press Impersonate on the requester's row again and confirm.
  2. Open Workflow Executions and press Open Workflow Session on the run.
  3. The agent has reported what it did and is waiting for you:

The instance id and its state, once the launch time you gave has passed. Check the instance in the AWS console if you like, then confirm in the chat.

  1. The agent closes with its summary, the last task completes, the run turns completed, and the bell shows a completion notification.
  2. Stop.

Afterwards​

The instance keeps running, and costs money, until you terminate it in the AWS console.

Two records the tour left behind are worth a look:

WhereWhat it shows
Audit Logs → ImpersonationsEvery session you just opened: who acted as whom, and when. Each write above is attributed to the impersonated account, so this trail is what answers "who was really behind it" (Audit trail)
The run's Tool Invocations pageEach tool call the run made and the certificate it presented — the approval you granted is what unlocked the one that did the work (Tool Invocations)