vellum.ai: What the Personal AI Assistant Does
Nov 4, 202613 min read
Vellum released a personal AI assistant. Vellum's the company behind the vellum.ai workflow and agent platform, and its own pages confirmed the release when checked on 2026-11-04.
Vellum.AI launched a personal AI assistant
For automation teams, the first question's who owns the connection between it and their existing workflows, whether those are built in-house or on tools like Activepieces.
What vellum.AI released and when
Treat anything outside these lines as unverified until you read it on the maker's site. The facts below come from Vellum's pages and show how much is confirmed.
- Released by Vellum, the company that operates vellum.ai.
- Product type: a personal AI assistant, announced as a Vellum launch.
- Announced on Vellum's own website, not through a third-party channel.
- Maker's pages last checked on 2026-11-04.
Any team wiring the assistant into a workflow engine should therefore assume that someone will have to set up and own that connection, because the list gives no connector, authentication method or permission scope.
This is a product bet rather than a demo, and Vellum's funding explains why. It raised $5 million in its 2023 seed round, so early work ran on a small budget.
It then raised $20 million in a 2025 Series A, four times the seed, which paid for a larger team. A $25 million Series A in 2026 brings the total to $50 million and means the company can keep supporting a launch like this one.
Nothing Vellum changes after that date is reflected here. Every launch fact and funding figure comes from Vellum's own pages, checked on 2026-11-04.
Everything below works on Activepieces' free plan. Start without code or a credit card.
What the launch enables for automation teams
Most automation teams already run agents, and that is why a personal assistant matters to them. The question's whether the assistant can call, or take work from, the workflows that exist. Everything else about it's secondary.
42% of enterprises have AI agents in production, according to Mayfield, which means deployment has crossed from experimental to standard practice. Another 30% are piloting and 28% are experimenting.
Put together, that means the whole sample's at least experimenting, and only the 28% still tinkering have nothing live to protect.
For the other 72%, a new assistant lands next to running schedules, triggers and credentials, and someone has to say how they meet, so the integration strategy emerges from ad-hoc conversations rather than planned architecture.
Assistant versus workflow
A workflow starts on a schedule or an event, runs fixed steps, and uses a connection that a named service account owns. An assistant starts when a person asks, decides its own steps, and acts under that person's access.
The first's repeatable and auditable. The second's flexible and tied to one requester.
Look at the illustration below and you see two lanes side by side: scheduled and trigger-driven boxes on the left, a person talking to an assistant on the right. Arrows labelled "call" and "hand off" run both ways between them.
Take from it that the value sits on those arrows, not inside either lane, and each arrow's a connection someone must own.
Today those arrows are built from general parts, such as webhooks and API calls, not a native Vellum integration. Each one carries a token, and each token has an owner.
Before anyone connects the assistant, settle these in order:
- Name the owner of every connection the assistant will use, and whether it runs on a personal login or a service account.
- Set the scope of each token to the narrowest permission the task needs.
- List the work that stays in a workflow because it must run unattended or leave an audit trail.
- Define which results the assistant may hand back into a workflow, and which require a person's approval first.
What is measurably new, from vellum.AI's own facts
Vellum.ai publishes its plans and prices: a free Base plan and a paid Pro plan. Any capacity planning rests on assumptions you must label as such.
Read the table below as a gap list. It records what vellum.ai states on each point as of 2026-11-04. Only the first row has any substance, and every other row's a question to put to the vendor before the connection gets an owner.
| Item | What vellum.ai states | Source page | Checked |
|---|---|---|---|
| Features | A personal assistant, as announced at launch | vellum.ai launch announcement | 2026-11-04 |
| Usage limits | not published | none found | 2026-11-04 |
| Pricing | not published | none found | 2026-11-04 |
| Availability | not published | none found | 2026-11-04 |
| API or MCP access | not published | none found | 2026-11-04 |
Without a published API or MCP statement, a call into your existing workflows can't be assumed to be native. It has to be built from general parts, and whoever builds it owns the credential.
You can't alert on a quota you can't read, so the first failure may be a silent throttle in a workflow that nobody was told depends on it.
None of the pricing or plan limits are published, and no plan price, request quota or rate limit appears on the pages checked.
Four items are missing: usage limits, pricing, availability and API or MCP access. Ask for each in writing, and record who at your organisation holds the token that will call the assistant.
Until those answers arrive, treat every number you see about this launch from another source as unverified for vellum.ai.
What workflow connections vellum.AI enables today
Today you can connect vellum.ai only through general parts, such as an HTTP request step, an AI step pointed at a custom provider, or an MCP server, none of them confirmed as native. We checked the platform's repository and catalog on 2026-11-04 and found nothing specific to vellum.ai, so there's no native connector.
We haven't run vellum.ai ourselves, so everything below is a design to test, not a verified recipe.
Each step up adds a part that can break, and the three options run from least setup to most. Decide first who owns the connection, because every option needs a credential held by a named person or service account.
Connect vellum.ai with an HTTP request step
You need an endpoint vellum.ai documents for starting work, plus a token scoped to that action only. Store it as a secret in the workflow, owned by a service account rather than an individual.
What could fail: the token belongs to someone who leaves, the endpoint changes without notice, or the call returns before the work finishes and the workflow carries on with an empty result.
Connect vellum.ai with a custom provider AI step
If vellum.ai doesn't expose an OpenAI-compatible interface, a base URL and a key, this option is closed. When it does, compatibility is often partial, so tool calls or streaming may behave differently from what the step expects.
The step also sends your workflow data to a third party, so check what the key permits before pointing it at records.
Connect vellum.ai assistant through an MCP server
An MCP server that exposes vellum.ai's assistant or tools needs a host to run it and a credential for each tool it exposes.
What could fail: the server's an extra service someone must patch and monitor, and its permissions can be broader than the task needs. Review the tool list before you connect it.
Activepieces covers the workflow side of this, where the assistant needs something to call.
Once a integration is connected in a project, an agent can use it: the same integration action that runs as a step in a flow is also exposed as a tool on that project's MCP server, which any MCP-capable client can use, whether that is Claude, ChatGPT, Cursor or an agent of your own.
Nothing is exported or registered a second time for any of the 747 integrations, which matters here because a catalog you must re-integrate for your agents is a second migration.
The mechanism sits in packages/integrations in the open source repo, and MoneyGram, Moneypenny, Alan and FundingSocieties run it.
Only the first option is worth trying before you have answers on vellum.ai's interface; the other two depend on it.
Easier to see it running than to read about it: set it up free, no card.
Comparing cost and speed of vellum.ai integrations
On published facts, the direct model call, the hand-used chat assistant and vellum.ai's assistant all have prices you can read today; vellum.ai's assistant has no published speed figure.
Price models of vellum.ai integration options
The table sets the three options side by side. Two rows are filled and the vellum.ai row's empty, so any cost estimate for it's a guess.
| Option | Price model | Setup effort | Published speed figure |
|---|---|---|---|
| vellum.ai assistant | not published | not published | not published |
| Workflow with direct model call | Per million tokens, input and output priced separately | Build and maintain the call; someone must own the API key | not published |
| Chat assistant used by hand | Monthly plan, from $0 | Account only; a person does every handoff | not published |
When a workflow makes a direct call, the bill goes to whoever owns the API key.
On an earlier snapshot of Vellum's coding leaderboard, Claude Opus 4.7 was listed at $5 input and $25 output per million tokens, so a long generated answer cost five times what the same length of prompt did.
Claude Sonnet 4.6 was listed at $3 and $15, GPT-5.3 Codex at $1.75 and $14, and DeepSeek V3 at $0.27 and $1.10. The gap between the top and bottom rows is roughly twentyfold on input, so model choice moves the bill more than workflow design does.
Chat plans are flat. ChatGPT runs $0 free, $8 on Go and $20 on Plus per month, which means anyone can try ChatGPT without paying.
Claude is $0 free, with limited usage every 5 hours and every week, so continuous free Claude use isn't possible. Spend is predictable, but a capped plan stops mid-task and a person remains the integration.
None of the three rows carries a speed figure in the sources used here. Vellum's leaderboard prices models but, in the figures above, gives no latency, so any claim that one option is faster is untested.
Ask for latency, with the connection owner named, before committing a workflow.
What to watch next at vellum.AI
If the answer to the latency and ownership question appears, it will be in one of three places vellum.ai controls: its changelog, its documentation and its pricing page. Each can be checked against the baseline of 2026-11-04, and none requires guessing what the maker intends.
So that a change shows up as a difference from that baseline and not as a feeling, re-read the list below on each check.
- Changelog entries that mention an API
- Changelog entries that mention MCP (Model Context Protocol, the standard for exposing tools to an assistant)
- Documentation on API or MCP access, including which token type or permission scope a caller must hold
- Pricing page changes
Once an entry appears, the next step's to find out who owns the connection it describes, and under which plan.
An entry naming an API or MCP endpoint is a stated feature, so count only what the changelog and docs say in plain words. A launch post describing the assistant as "connected" isn't one, because it names no scope, no caller and no owner.
If access appears only on a higher plan, the workflow's owner needs budget approval before anyone builds against it. Record which plan the pricing page ties to API or MCP access, and which limits it lists.
Where the pages give no response time, rate limit or call quota, write "not published" in your handover notes. Don't substitute an estimate. Put the question to vellum.ai in writing, name your own connection owner beside it, and keep the reply with the workflow's records.
What Activepieces does about this
The gap this article keeps returning to is the connection nobody owns, and Activepieces is built to be the workflow side of it.
It is an open source automation platform under the MIT licence for its community edition, so the engine that holds your schedules, triggers and credentials is code you can read and self-host, not a service whose terms change under you.
That matters when the thing calling into it is an assistant whose own API and MCP access are not yet published.
The practical integration is the one already described above. Once an integration is connected in a project, the same action that runs as a step in a flow is also exposed as a tool on that project's MCP server.
Any MCP-capable client can call it, whether that is Claude, ChatGPT, Cursor or an agent you wrote. If vellum.ai later publishes MCP support, the route to your existing workflows is a client pointed at that server, with no second catalog to build.
Until it does, the same flows can start from a webhook trigger, so the HTTP request option in this article has a receiving end that a service account can own.
We have not run vellum.ai against Activepieces, and nothing here claims a native Vellum connector.
What you can point at is the other half of the checklist: the token for each connection lives in a project with a named owner, and work that must run unattended or leave an audit trail stays in a flow rather than moving into an assistant acting under one person's login.
MoneyGram, Moneypenny, Alan and FundingSocieties run Activepieces in production, which is the kind of unattended, audited workload that list is meant to protect.
So the useful first step is small. Stand up a flow with a webhook trigger, scope its token to one action, record who owns it, and test a call from any general client before vellum.ai answers your questions about limits and access.
If the answers come back favourable, you will already have the owner, the scope and the audit trail in place.
