Build the AI roleyour business needs.

No. The library is a set of examples: the shapes we build most often, written down so you can see the range. Every build starts from scratch around one business. Two clients can point at the same card and receive two different systems, because the workflow underneath is never the same.

Describe your work. That is what the first call is for: we map the role as you actually run it, then decide together what to build. If a card here matches, it becomes a useful reference point. If nothing matches, nothing is wrong; the card was never the product.

From your own material. During the build it is set up on the way you already work: past replies for the tone, your policies for the rules, your systems for the live data, and the exceptions your team already solved for the judgment calls. That context is tested and tightened against real cases before the agent touches production.

Yes. An agent covers a responsibility, and responsibilities rarely live in one tool. A refunds agent reads the helpdesk, checks the order in your store, prepares the credit in your payment system and leaves the note your bookkeeper will look for. If the required access and endpoints are available, it can sit inside the workflow; we verify that before scope is locked.

The range is repeating work with a system behind it, not the cards on this page. Some of the most valuable agents we build come from workflows that exist in exactly one company, which is why the library ends with the card without a card. Bring the odd one to the first call.

They take over the repeating part of the week, and what that means depends on where you stand. The owner gets out of the inbox. The swamped team stops answering the same question forty times. The hire you were about to make for pure throughput can wait, and the agency's senior people stop assembling reports. The judgment calls stay with people, by design; the gates make sure of it.

A chat window helps when someone sits down, pastes in the context and asks. An agent is wired into your systems, carries that context permanently, runs on its own rhythm and stops at your gates. One is a tool a person uses. The other covers a role, whether or not anyone opened a tab that day.

You own the delivered system: the code, the credentials, the documentation and the runbooks, in a repository under your own GitHub organisation from the first commit. Vulc keeps the generic building blocks and the know-how that carry between builds. Your data and your configuration never become anyone else's building block.

The agent keeps running in your environment, on your accounts. If you want it tuned and extended as your business moves, there is an optional monthly retainer. If you would rather run it yourself, the documentation and runbooks are written for exactly that, and nothing of ours stays behind.

Every action that touches a customer or moves money stops for sign-off until you decide otherwise. Routine cases can earn standing approval; thresholds catch the rest, so everything above your line arrives as a prepared draft, one decision from done. You set the lines at the start and move them as trust builds.

With the role that eats the most of the week. For one business that is the support inbox, for another the monthly client reports, for a third the catalog work or the lead intake. One well-built agent proving itself beats five ideas on a whiteboard, and the next agent joins the same approval surface when you are ready.