Documentation for the TicketFlow demo platform.
TicketFlow is a demo platform for testing AI agent integrations via MCP (Model Context Protocol). It includes a ticket management system as a built-in use case — agents can create, search, and update tickets — but the primary purpose is to evaluate how different MCP servers, models, and prompts perform on real tasks.
The agent uses Anthropic models (Claude) and runs on a shared corporate API key — no personal API key is needed.
The Home page gives you an overview of your workspace at a glance.
The core of TicketFlow. Each ticket has a title, description (Markdown), status, and visibility.
Backlog — not startedOpen — in queueIn Progress — being worked onDone — completedSwitch between List and Kanban board using the toggle in the top-right corner of the Tickets page.
Filter by status and ownership (All / Mine). Use the search field to find tickets by title or description.
MCP (Model Context Protocol) profiles connect the agent to external services — CRMs, messengers, databases, and more. Each profile is a URL + token pair pointing to an MCP-compatible server.
Every account has the TicketFlow profile pre-connected. It gives the agent access to native ticket management tools (create, list, update, delete tickets).
Albato provides a public demo MCP server for testing. Use it to explore how agents work with MCP tools before connecting your own server.
https://mcp-demo.albato.com/mcpAuthorization: Bearer <token> is usedAlbato Demo, URL — https://mcp-demo.albato.com/mcp, Token — the session token from step 1.Albato provides a demo MCP server at https://mcp-demo.albato.com/mcp. Virtual keys let you connect agents securely — your real Albato API token is stored server-side and never sent to the LLM provider.
A virtual key (mcp_vk_...) replaces your real Albato API token in the agent configuration. If a virtual key is ever compromised, you revoke it in one API call — your real token is unaffected and all other agents keep working.
You need a Registration Secret (reg_...) provided by your Albato integration manager. Each company gets one — keep it safe, it allows creating new keys on behalf of your contract.
curl -X POST https://mcp-demo.albato.com/auth/register \
-H "Authorization: Bearer <registration_secret>" \
-H "Content-Type: application/json" \
-d '{
"albatoToken": "<your_albato_token>",
"label": "ticketflow-agent",
"expiresAt": "2026-12-31T23:59:59Z"
}'label is optional but recommended (e.g. "crm-agent", "onboarding-flow"). expiresAt is optional — omit for a permanent key.
The response includes "virtualKey": "mcp_vk_...". Save this value immediately — it is shown only once and not stored on the server.
https://mcp-demo.albato.com/mcp.mcp_vk_... value as the Token.curl https://mcp-demo.albato.com/client/keys \
-H "Authorization: Bearer <registration_secret>"The response shows a keyHint (last 4 characters of the key), label, and expiry for each key.
curl -X POST https://mcp-demo.albato.com/client/keys/revoke \
-H "Authorization: Bearer <registration_secret>" \
-H "Content-Type: application/json" \
-d '{"virtualKey": "mcp_vk_..."}'Effect is immediate — any subsequent request using the revoked key returns 401.
401 — invalid, revoked, or expired virtual key; or invalid Registration Secret400 — missing required field, or expiresAt is in the past503 — server unavailable, contact your integration managerAn agent is a configured AI assistant. You can create multiple agents with different models, system prompts, and connected MCP profiles.
Each agent card in the Agents list shows token consumption for today, the last 7 days, and the last 30 days. If a limit is configured, the card also shows what percentage of the limit has been used. A red daily / weekly / monthly limit badge appears when a limit is reached and the agent is blocked.
When a token limit blocks a scheduled run, a service notice is written to the chat so you know why a particular run was skipped. Subsequent blocked runs in the same period do not add duplicate notices.
Every agent has a unique webhook URL and secret, visible in the agent's edit form. External systems (such as Albato) can trigger the agent via a simple HTTP API without user interaction.
POST request to the agent's webhook URL with the X-Webhook-Secret header and any JSON body. The entire body is passed to the agent as the user message — use the agent's system prompt to define how it should be handled. Optionally include a prompt field to override with an explicit instruction, and a session_id to continue an existing conversation.202 and a job_id + session_id.GET /api/hooks/jobs/<job_id> until status is done or failed.Pass the same session_id in subsequent calls to continue the same conversation. Omit it to start a new one. Each session corresponds to a chat visible in the Chats section.
Each agent has a Chat session mode setting in the webhook section of its edit form:
session_id gets its own chat. Pass the same session_id across calls to continue a specific conversation.session_id, accumulate in one persistent chat. The full conversation history is passed to the agent each time, so it can refer back to all previous calls.Use Single chat when you want the agent to have memory across independent webhook events (e.g. an agent that tracks mentions over time and builds a running summary).
Webhook-triggered runs appear in Chats with a blue webhook badge. Each turn shows the original request body (prompt and context) and execution metrics (duration, input/output tokens). The Journal also logs every webhook run with a job ID for traceability.
Every agent can have one or more schedules — timed triggers that run the agent automatically with a given prompt, without any manual interaction.
0 9 * * 1-5). Use crontab.guru to build and verify expressions.Use these placeholders in your prompt — they are substituted at run time in the schedule's timezone:
{{date}} — today's date in ISO format (e.g. 2025-06-11){{time}} — current time (e.g. 09:00){{day}} — day of week (e.g. Monday){{yesterday}} / {{tomorrow}} — adjacent dates{{week_number}} — week of the year{{month}} — current month nameEach schedule has a Chat session setting:
Use the toggle switch next to each schedule in the list to enable or disable it without deleting it. Disabled schedules are preserved but never run.
Scheduled runs appear in Chats with a green scheduled badge. In Reuse same chat mode all runs accumulate in the same chat; in New chat each run mode each run gets its own chat. The chat header shows an Auto-update toggle that polls for new messages every 5 seconds — useful when watching a scheduled chat live. The Journal also logs every scheduled run with a scheduled badge.
Each agent can be used in a persistent chat. Conversation history is saved — you can close the browser and continue later.
During a response, you can see each tool the agent invoked and its result. This helps you understand exactly what actions were taken on external services.
When an agent is triggered via webhook, a chat is automatically created or continued for that session. These chats appear in the sidebar with a blue webhook badge. Each turn in the chat shows:
You can continue a webhook conversation manually by typing in the chat input — the history is preserved across both webhook-triggered and manual turns. The session UUID is shown in the chat header and can be copied to use as session_id in the next webhook call.
The Testing section lets you compare up to 4 agents simultaneously on the same set of tasks — useful for evaluating different models, prompts, or MCP configurations.
You can use the same agent on both sides but with different MCP profiles attached — for example, to compare Albato vs Composio on the same task:
Cost is calculated automatically from token counts using current Anthropic pricing. Hover over a bar in the chart to see the per-case breakdown (input vs output tokens and their rates).
temperature = 0 on both agents.The Journal shows a log of all agent runs — from Chats, Testing, and Webhooks. Each entry includes the message sent, token usage, duration, MCP profile used, and any errors.
Filter by date range, tool name, or error status. Click any row to expand the full tool call trace.
Administrators see sessions from all users and can additionally filter by user. They can also hide sessions from the list, add notes, and delete sessions older than a given date.
Available to administrators. Shows a log of all agent sessions across all users.
Sessions can be filtered by user, date, tool name, and error status. Individual sessions can be hidden from the list or annotated with a note.
Administrators can manage all user accounts in the Users section.
New registrations default to Pending. An admin must approve them before they can log in.
Approve, block, or delete users. Enable or disable agent access per user. Admins cannot modify their own status or delete themselves.
Administrators can also delete any ticket, including tickets created by other users.
Anthropic API Key — optionally set your own API key. If not set, the platform uses the shared corporate key. Useful if you want to track your personal usage separately.
Always confirm connection — when enabled, the agent will always ask you to choose a connection before performing any action, even if only one is available. Useful for demos where you want to make the flow visible step by step.
Custom instructions Admin — text appended to the system prompt for all agents and all users. Use it to set the default tone, restrict certain behaviors, or add shared domain context.
Customize the app for your workspace: set a name, pick an accent color, and upload a logo. Changes apply immediately and are visible only to your account.
Change your password. Passwords must be at least 8 characters and include an uppercase letter, a number, and a special character.
Administrators can now log in as any non-admin user directly from the Users table. Click Impersonate next to a user row — the page reloads showing the app exactly as that user sees it. A red banner at the top of the screen identifies the active impersonation session and shows the user's email. Click Exit in the banner to instantly return to your admin session. Impersonation sessions expire after 8 hours. Other admins cannot be impersonated.
Administrators can now disable scheduled agent runs for individual users via the Disable schedules / Enable schedules buttons in the Users table. When schedules are disabled for a user, all their active schedules are silently skipped at runtime. The affected user sees a yellow notice on the Agents page, and the Schedules section in each agent's settings is greyed out with a "Disabled by administrator" label.
In addition to per-agent limits, administrators can now set account-level daily, weekly, and monthly token limits for individual users via Set limits in the Users table. These limits apply across all of a user's agents and all run sources (chat, webhook, scheduled). Current consumption (D / W / M) is shown inline in the Users table; values that exceed the limit are highlighted in red with a ⚠ indicator. Leave a limit blank to make it unlimited.
Agents now have a Chat session mode option in the webhook settings. In the new Single chat mode, every incoming webhook call for an agent — regardless of session_id — is appended to one persistent chat. The full conversation history is passed to the agent on each call, giving it memory across independent events. The default Per session mode is unchanged.
Webhooks now accept credentials via the standard Authorization header in addition to the custom X-Webhook-Secret header. Pass the secret as the second part of any scheme: Authorization: Token <secret>, Authorization: Bearer <secret>, etc. Both headers work simultaneously and are fully backward-compatible.
The prompt field in the webhook request body is now optional. If omitted, the entire JSON body is passed to the agent as the user message. This lets you forward arbitrary event payloads — from Albato, Zapier, or any service — without reshaping the data. Describe the expected format in the agent's system prompt instead.
Agents can now run automatically on a schedule — no manual interaction needed. Each schedule has a name, a prompt with optional template variables ({{date}}, {{time}}, {{day}}, and others), a timezone, and a frequency (preset intervals or a custom cron expression).
Two chat session modes: Reuse same chat (all runs accumulate in one persistent chat, so the agent can refer to previous results) or New chat each run (each run gets a fresh context). Schedules can be paused and resumed without deleting them. Scheduled runs appear in Chats with a green scheduled badge and are logged to the Journal.
Each agent card now shows token consumption for today, the last 7 days, and the last 30 days — across all sources (chat, webhook, and scheduled runs). Optionally set a daily, weekly, or monthly limit. When a limit is reached, the agent stops accepting new requests and writes a service notice to the chat. Subsequent blocked runs in the same period add no duplicate notices. The daily limit resets at midnight in your account timezone; weekly and monthly are rolling 7-day and 30-day windows.
A new Timezone field in Settings → Account controls when the daily token limit resets.
Tool call results in the Journal now have a Raw / JSON toggle. The JSON tab renders structured data as a collapsible tree with colored value types and a Copy button — similar to Postman's response viewer.
Each agent now has a unique webhook URL and secret — making it possible to trigger agents from outside the platform: via an Albato automation, a custom script, Postman, or any HTTP client. The agent runs asynchronously and returns its result via a polling endpoint.
Webhook-triggered agent runs are now fully visible in the UI. Each webhook session automatically creates a persistent chat with a blue webhook badge — you can watch the conversation unfold and continue it manually from the chat input.
session_id in the next webhook call to continue the conversation.Agent runs can now be cancelled mid-flight. The Send button turns into a Stop button while the agent is running — clicking it immediately cancels the request in both Chats and Testing.
The Testing section now streams agent progress live — you can see each tool call as it happens, without waiting for the full run to complete. This also eliminates timeout errors on long-running agents.
Each user can now connect their own MCP server under Settings → MCP Profiles. Any MCP-compatible provider is supported (Albato, Composio, and others). Tokens are encrypted before storage.
A built-in TicketFlow profile with native ticket management tools is automatically added to every account.
The Agents section lets you create custom AI agents with their own system prompt, model selection (Sonnet, Haiku, Opus), MCP profile bindings, iteration limit, and temperature. The platform uses a shared corporate Anthropic API key — no additional setup required.
Each agent is accessible via persistent chat with full history. The chat streams responses and shows tool calls and their results inline.
The Testing section lets you compare agents on identical tasks — side by side, with metrics on tokens, cost, and time. An AI-generated summary highlights the key differences. Each run includes a detailed breakdown of tool calls and responses.
Cost is calculated automatically using current Anthropic pricing, with per-case breakdowns of input/output tokens.