Your Cloud. Your Model. Your Rules.

Connect WorkflowGen to the LLM already running in your Amazon Bedrock account or Microsoft Azure subscription — and put AI to work inside the processes your business already runs on.

BY
WorkflowGen Team

The starting point: you already have the model. The gap is the process.

Frontier models are one API call away. Amazon Bedrock puts Claude, GPT, Llama, Mistral, Nova and others on the AWS account you already run. Microsoft Foundry puts GPT, Claude, Mistral and Llama on the Azure subscription you already pay for. Very few organizations have those models doing measurable, auditable work inside an approved business process.

A notebook or a chat window makes one person faster. It does not route an invoice, enforce a control or produce evidence. Security asks where the data goes and who approved what. Without an answer, nothing reaches production.

The work is the integration. Value sits in the ERP, the CRM, the document store — and in the human decisions that connect them. WorkflowGen is the layer in between: a governed process platform that calls the model in your own cloud account, keeps a named human accountable for the outcome, and records every step in one audit trail.

01 — Connect your own model

No new AI vendor. No new contract. No data leaving the AWS account or the Microsoft perimeter your security team has already approved.

Three steps, one afternoon

WorkflowGen ships with a built-in AI workflow application. Bedrock now exposes OpenAI- and Anthropic-compatible endpoints; Azure Foundry is supported as an OpenAI-compatible provider. Connecting either is configuration — not development.

On Amazon Bedrock

  1. Enable the model. Request access to the model you want in your own account and Region, then generate a Bedrock API key from the console or IAM. No account with a model vendor. Short-term keys for production. Every call logged in CloudTrail.
  2. Point WorkflowGen at it. Use the Bedrock OpenAI-compatible or Anthropic-compatible endpoint as the base URL and the Bedrock API key as the key. Set this in web.config, or override it per action.
  3. Use it in a process. Drop the OPENAICHAT application into any workflow step. MODEL and messages go in; RESULT_CONTENT and token counts come out as process data you can route on.

On Microsoft Azure / Foundry

  1. Deploy the model. Create a Foundry resource in your own subscription and deploy the model you want. Azure issues the endpoint and the key. Entra ID authentication is supported. No third-party account.
  2. Point WorkflowGen at it. Set OpenAIChatApiUrl to the Azure endpoint and OpenAIApiKey to the Azure key, once in web.config or per action. Azure is treated as an OpenAI-compatible provider.
  3. Use it in a process. The same OPENAICHAT application. The same inputs and outputs. Reusable in every process.

Nothing to build, nothing to maintain. No connector development, no middleware, no custom code. Because the same mechanism drives a self-hosted model, changing model later is a change of URL — not a project.

Any model. No lock-in, technical or commercial.

WorkflowGen is LLM-agnostic by design. Bedrock is multi-provider by design. Foundry puts first-party and partner models in the same portal. Your model strategy stays yours — and it can change next quarter without touching a process.

On Amazon Bedrock. Claude Sonnet and Haiku are reached through WorkflowGen’s Anthropic provider, on the Anthropic-compatible endpoint. Everything else on the account — the GPT family and gpt-oss, Mistral, Llama, Amazon Nova, DeepSeek, Qwen, MiniMax, NVIDIA Nemotron, xAI Grok — is reached through the OpenAI-compatible endpoint at /v1/chat/completions, using WorkflowGen’s OpenAI provider. Same model, your account, your Region.

On Microsoft Foundry. Models sold by Azure — the GPT-5 family, Mistral, Llama, Cohere — sit under Microsoft Product Terms and are billed on native Azure meters, against the commitment you already have. Partner models such as Claude and Hugging Face are deployed from the same portal and billed via Azure Marketplace as a non-Microsoft product. Same Azure invoice, provider licence terms accepted on subscription.

Or nothing from AWS or Azure at all. The platform does not care. OpenAI, Anthropic, Mistral, Gemini and DeepSeek direct; self-hosted Ollama, vLLM, LM Studio or LocalAI; a model on your own infrastructure, fully air-gapped. Mix providers across processes in one platform.

Changing model = a new endpoint and a new MODEL value. Your processes, forms, participants and audit trails are untouched.

What it costs — and how you keep control

No AI licence. No seat count. No minimum. You pay for the tokens your processes consume, on the invoice you already receive. A first process typically costs tens of euros a month — not a subscription for the whole company.

  • Right-size the model at every step. Classification and extraction run on a small model; only genuine reasoning needs the large one. WorkflowGen sets MODEL per action, not per platform.
  • Choose the service tier per workload. Batch and Flex on Bedrock cost half the standard price for work that can wait. Azure Batch is 50% less; prompt caching can cut input cost dramatically on both clouds. Provisioned throughput turns a variable cost into a fixed one when you are ready.
  • Every call returns RESULT_TOTAL_TOKENS, RESULT_PROMPT_TOKENS and RESULT_CACHED_TOKENS into the process — so AI cost is reportable by process, by entity, by month.

Indicative on-demand list prices (confirm in the AWS and Azure pricing calculators; they vary by Region and date): Amazon Nova Micro at $0.04 / $0.14 per million tokens in / out; Nova Lite $0.06 / $0.24; Nova Pro $0.80 / $3.20; Claude Sonnet 4.6 $3.00 / $15.00. On Azure Global Standard, GPT-5.4 nano $0.20 / $1.25; mini $0.75 / $4.50; GPT-5.4 $2.50 / $15.00; GPT-5.5 $5.00 / $30.00. Cached input and batch tiers are substantially lower.

The data stays inside an account you already control

No new processor to assess. No new contract to negotiate. The model runs in your AWS account or under your Azure subscription, in the Region you choose, under the agreement you already signed.

  • Never used to train models. AWS states that your data is not shared with model providers and is not used to improve the base models. On Azure, prompts and completions are not used to train foundation models, not shared with other customers and not available to the model provider.
  • Encrypted, with your own keys. In transit and at rest. Customer-managed keys in AWS KMS or Azure Key Vault.
  • Your Region, and it stays there. A US inference profile on Bedrock keeps every request inside US Regions — routing beyond the US is opt-in. Azure Data Zone deployments keep processing inside the local Data Boundary; US, EU and APAC zones and single-region pinning are available.
  • Your identity, your network. IAM policies and condition keys on AWS; Entra ID, conditional access and private networking on Azure. PrivateLink / private endpoints keep traffic off the public internet.
  • Auditable by default. CloudTrail plus optional model invocation logging to your own S3 bucket on AWS. Foundry is covered by the Microsoft Products and Services DPA already in force. Abuse-monitoring opt-out is available on Azure for customers who apply.
  • Certified where it matters. ISO, SOC and CSA STAR in scope on both sides. HIPAA eligible. In GovCloud (US), Bedrock models carry FedRAMP High and DoD IL-4/5 authorization.

And on the WorkflowGen side of the line: every AI call, the data sent, the answer returned and the person who accepted or overrode it are recorded in the same audit trail as the rest of the process.

02 — Put AI to work in a process

AI stops being a demo when it reads the attachment, fills the form, drafts the recommendation — and hands a named human the decision. None of the patterns below requires redesigning the workflow. Each is a step added to an existing process, with the human approval left exactly where it is today.

  • Document analysis. Attachments are read, classified and their key data extracted — invoices, contracts, certificates, claims — then written straight into the process.
  • Decision support. Search and analysis across your internal knowledge, returned to the approver as a structured recommendation with pros, cons and risks.
  • Wider input sources. Audio, video, images and email become usable process inputs, widening what can be automated beyond structured forms.
  • Notifications people read. Recipient-specific emails that say what happened, what is needed and by when — generated per request, not templated.

All of it runs against your Bedrock or Azure endpoint. Structured output against a JSON schema, function calling, conversation history and token accounting all come back into the process as data your workflow can branch on.

Retrieval-augmented generation, grounded in what you already decided

WorkflowGen v10 indexes request data with embeddings generated by your own Bedrock or Azure endpoint, so an AI step reasons over your history instead of guessing from the public internet.

  • Extract. EXTRACTTEXT pulls clean text out of PDF, DOCX and TXT attachments.
  • Embed. Request data is chunked and vectorized by an embedding model on your own endpoint.
  • Store. Vectors stay in your own database: PostgreSQL with pgvector on Amazon RDS or Aurora, SQL Server, or Azure SQL.
  • Retrieve. SEMANTICSEARCH combines full-text and semantic search, and feeds the result to the model.

What that changes for the person who has to decide: the three most similar past cases can be surfaced on the approval form before the approver commits. “Vendor delays similar to Q2” returns the right requests even when nobody used those words. Every request completed becomes searchable context for the next one, across processes and entities.

The knowledge base is yours and stays yours. Embeddings are generated by your model and stored in your database, inside your VPC. Nothing is uploaded to a third-party index.

03 — Agents, in both directions

AI agents working inside your processes — and the agents you already have on AWS or Azure calling WorkflowGen when a decision needs a person.

Agents that act — inside a process that answers for them

An agent able to call tools needs boundaries. WorkflowGen supplies them: declared tools, a defined sequence, and human checkpoints where the consequences are real.

What the agent can do

  • Call the tools you declare, in OpenAI function-calling format
  • Return structured JSON validated against your own schema
  • Carry conversation state across several process steps
  • Route the request based on its own confidence score
  • Hand off to another agent, passing data between them

What the platform enforces

  • Which tools exist, and which this agent is allowed to use
  • A human checkpoint wherever you decide the stakes justify one
  • Escalation when confidence is low or an exception is met
  • A record of the prompt, the answer, the tokens and the outcome
  • Versioning — changing a prompt is changing a process version

Tasks are assigned dynamically by complexity, context and workload. Agents pass data to one another, a named person keeps the final word, and every step — human or machine — lands in the same audit trail.

Your cloud agents can start, feed and complete a process

A Bedrock AgentCore agent, a Lambda function, a Step Functions state machine, a Copilot Studio agent, a Logic App, a custom Foundry agent or anything else in your landscape: WorkflowGen exposes the process as an operation they can call.

  • Incoming webhooks. One HTTP POST, JSON payload — create a request, complete an action, update a dataset, reassign, cancel or delete. Token-authenticated, with optional user impersonation.
  • GraphQL Web API. Full runtime and design-time: requests, actions, users, groups, participants, delegations, process import and export. Enough to build a custom portal — or to let an agent drive one. Secured by the same identity model as the portal.
  • Outgoing webhooks and apps. Process events, RESTAPICLIENT for any REST service, .NET assemblies and Node.js. Any AWS or Azure service reachable over HTTPS. Digital signing, ERP and CRM through the same mechanism. Teams approvals already run this way via Power Automate.

On AWS, AgentCore Gateway turns those endpoints into MCP tools today: register the WorkflowGen API as an OpenAPI or Lambda target and Gateway publishes it as MCP tools your agents discover and call, with inbound and outbound auth handled for you. On Azure, WorkflowGen is adopting MCP so agents can discover and call your processes through a standard interface.

An agent framework is not a process platform

AgentCore gives your agents a runtime, memory, identity and a gateway. Copilot makes individuals faster inside Word, Excel, Outlook and Teams. Neither gives you the human process around the agent. Most of our customers run both.

An agent framework is a runtime for autonomous agents — built and operated by your developers. It has no forms, no approvers, no delegation, no process version. Microsoft 365 Copilot is licensed per user, per month, grounded on the content one user can already see, with no process state, no routing and no approval record.

WorkflowGen is governed process automation: cross-functional processes with defined steps and owners; forms, participants, delegation, escalation, supervision; built and changed by business analysts, not developers; a complete audit trail, including what the AI proposed; twenty years of process semantics an agent framework has no reason to have.

Where the two meet: your agent calls WorkflowGen through Gateway, Copilot Studio or a webhook when a decision needs a person; the process runs, applies your controls and produces the evidence; the outcome returns to the agent or back into Microsoft 365.

How it fits together

One governed process engine in the middle. Everything else stays where it is — including the model.

  • WorkflowGen — process engine, AI apps, GraphQL API. Runs on AWS, Azure or on-premises. .NET engine with a Node.js layer, web farm with load balancing, SQL Server or PostgreSQL.
  • The model — Amazon Bedrock or Microsoft Foundry, in your account.
  • Your data — Amazon RDS or Aurora PostgreSQL with pgvector, SQL Server, Azure SQL.
  • Identity — SAML, OpenID Connect, LDAP, Active Directory, Entra ID and SCIM.
  • ERP, CRM and line-of-business systems — SAP, Salesforce and the rest, reached the same way they always were.
  • Agents and automation — AgentCore, Lambda, Step Functions, EventBridge; Copilot Studio, Logic Apps, custom agents.
  • Digital signing — DocuSign, Adobe Sign, Docaposte, YouSign.
  • Microsoft 365 — SharePoint, Teams, Entra ID — when that is the workplace.

How to start: one process, thirty days, no infrastructure project

The lowest-risk way to answer the AI question is to run one real process end to end — with your model, your data and your approvers.

  • Week 1 — Pick and model. Choose one high-volume, low-drama process with a clear owner. Model the flow and the form in the graphical designer.
  • Week 2 — Connect the model. Enable a small model in Bedrock or deploy one in Foundry, generate a key, point WorkflowGen at the endpoint and add the first AI step.
  • Week 3 — Run it live. Real requests, real approvers, real attachments. The AI proposes; the named human decides and can override.
  • Week 4 — Measure and decide. Cycle time before and after, token cost per request, override rate. Then choose whether to scale, adjust or stop.

Keep your model. Keep your budget. Keep the human in the loop.

Since 2003, WorkflowGen has been deployed by more than 500 organizations in 70 countries, processing millions of requests daily. Hybrid Agentic Process Automation is not a new category we invented for a slide. It is twenty years of process semantics with the model of your choice plugged in.

If you already have an AWS account or an Azure subscription, you already have the model. The next step is one process.

About the author

WorkflowGen Team
Follow

Continue reading with these additional posts

Transform Your Operations with Hybrid Agentic Processes!

Learn how our customers are combining AI and human expertise to drive smarter, more efficient workflows with WorkflowGen.