From Days to Minutes: How an Agency Built a Governed AI Agent Factory

From scattered experiments to a shared system

UK marketing agency Hallam started from a familiar situation: employees independently tested different AI services, while the business struggled to compare impact, control client data, and maintain a consistent working standard. Industry publication BusinessCloud reported a core team of 45 full-time employees—already too many experiments to keep in one manager's head.

Hallam moved individual trials into a shared environment with governed data connections and the ability to build specialised no-code agents. Department heads received 20% of their working time for AI innovation, while other employees received one day per month to experiment. A partner helped with licensing, technical setup, and training.

The Google Cloud customer story reports four notable changes:

• audience research fell from one or two days to 15 minutes;
• brief editing fell from half a day to 15 minutes;
• a contract negotiation plan could be prepared in 10 minutes instead of half a day;
• onboarding that used to take weeks could be delivered in the first two or three days.

These figures were supplied by case participants and published by the platform vendor. The story does not provide an independent audit, the full cost of licences and partner work, error frequency, test sample size, or the share of outputs that needed rework. The numbers indicate possible scale, not a guaranteed result for another company.

Why “another chat window” was not the answer

Hallam's key change was not a particular model. The agency created a governed space where an employee can build a tool around a process while using approved connections and shared data.

Previously, an automation request went through the technical team and could wait for weeks. After the change, a marketing specialist could build a forecasting agent, upload spreadsheets with historical metrics, account for seasonality, and produce forecasts for traffic and conversions. Developers could focus on deeper integrations and a central data layer.

This distinction matters for small and medium-sized businesses. Democratising development is useful when it reduces the IT queue. Without rules, it creates a second queue made of untested agents that duplicate functions and hold excessive permissions.

Four processes, four risk levels

**Audience research.** An agent analyses large sets of public discussions and focus-group material to identify recurring motives. A fast draft is reasonable, but a person must check the sample, sources, and representativeness. Otherwise, the model can confidently turn a vocal minority into “the market view.”

**Brief preparation.** An agent collects source material and maps it to the company template. Risk remains manageable when it fills fields from the CRM, contract, and approved template rather than inventing facts. The project owner approves the final brief.

**Contract review.** Staff upload redlined documents, while an agent highlights disputed clauses and proposes negotiation positions. This supports navigation; it is not legal advice. An accountable specialist or lawyer decides on risk, obligations, and wording.

**Onboarding.** Search over policies, processes, and project history helps a new employee find answers faster. Client and role boundaries are crucial: a newcomer must not see a document merely because a shared agent found it.

A single interface does not imply equal autonomy. Research may generate a report, briefing may produce a draft, contract analysis should produce suggestions with mandatory review, and onboarding should remain strictly read-only within the user's permissions.

Minimum architecture for an “agent factory”

A repeatable environment has seven components.

1. **Use-case catalogue.** Every agent records its owner, purpose, users, data sources, tools, permitted actions, and next review date.
2. **Creation template.** Employees select a task type rather than starting from a blank prompt. The template defines input, expected output, constraints, and quality criteria.
3. **Data layer.** RAG and connectors retrieve documents from approved repositories. Access is computed from user identity and permissions on the source object.
4. **Tool broker.** An agent receives only the functions it needs. Search does not include deletion, and an email draft does not include autonomous sending.
5. **Human gates.** Financial, legal, HR, and external actions require explicit approval. The interface shows exactly what will happen.
6. **Evaluation set.** Before launch, the agent is tested on common, rare, and conflicting examples. Measure completeness, factual errors, rework, and format compliance.
7. **Audit and budget.** Record instruction version, sources, tool calls, approvals, cost, and duration. Set usage and spending limits per agent.

OWASP describes excessive agency as excessive functionality, permissions, or autonomy. The practical consequence is simple: restrictions belong in APIs and access systems, not only in a model's text instructions.

Data preparation required

A fast agent over bad data spreads confusion faster. Before connecting enterprise search, establish:

• owners for folders and data sources;
• permissions by client, project, and role;
• current templates for briefs and contract positions;
• a metric dictionary and consistent field names;
• document expiry and version archives;
• reference examples of acceptable output;
• data that models must never receive;
• a procedure for removing a client and its material from the index.

For spreadsheets, fix the schema: period, currency, units, source, missing values, and seasonality. A forecasting agent should not decide which of two columns represents revenue. For text, preserve citations to source passages and document versions.

Where local models and hybrid deployment fit

A Russian company can copy the organisational approach without copying the platform. Client documents, contracts, financial indicators, personal data, the RAG index, and action logs can remain inside a controlled environment. A local model can handle retrieval, field extraction, classification, and drafting.

An external API may be appropriate for de-identified style editing or public-data research when policy and contracts permit it. A gateway removes names, payment details, and internal identifiers before transmission and validates the response afterwards.

Hybrid deployment makes sense when task sensitivity varies. Public-forum research may use an external model, while a contract agent remains local. Two environments, however, increase support cost: the company needs one agent registry, routing policy, observability, and a manual fallback.

Locality alone does not create security. If a shared service account can see every client folder, a local agent can still disclose too much. Permissions must inherit from the user, while high-risk tools should be absent from read-only workflows.

The economics of allocated experimentation time

Hallam did not ask employees to experiment “when they had a spare moment”; it allocated time formally. This improves the chance of producing working use cases but creates a material investment.

Consider a modelled 50-person company. One experiment day per month for 45 employees equals 360 hours. If five department heads additionally spend 20% of their time, that adds about 160 hours. The total is approximately 520 hours per month before licences, partner services, and support.

This is not a Hallam calculation. It is an illustration assuming an eight-hour day and 160 working hours per month. To prevent the investment becoming paid curiosity, every experiment needs a card recording baseline process time, expected reduction, volume, error risk, launch cost, and a date to scale or close.

Suppose an agent saves two hours on a brief and the company produces 20 briefs per month. The potential is 40 hours. If creation, evaluation, and rollout require 30 hours in month one and five hours thereafter, the use case may pay back. If the task occurs twice a year, a standard template is probably cheaper than an agent.

Management needs a portfolio rather than a count of agents. Useful measures include:

• hours verifiably released after output review;
• outputs accepted without substantial rework;
• active users and repeat runs;
• cost per accepted result;
• access incidents and erroneous actions;
• agents retired as duplicates or uneconomic.

Risks of democratisation

The first risk is a shadow agent: an employee creates a tool, leaves the company, and the workflow continues without an owner. Every agent needs an expiry date and automatic suspension without review.

The second risk is hidden access expansion through connected repositories. Authorise both indexing and every retrieval request.

The third risk is indirect prompt injection. A website, email, or document may contain instructions aimed at the model. External content is data, and tool calls receive separate validation.

The fourth risk is false confidence in legal and analytical output. The agent must expose sources, assumptions, and boundaries. High-risk output cannot reach a client without an accountable person.

The fifth risk is uncontrolled cost. No-code lowers creation cost but increases usage. Apply quotas, caching, model routing by complexity, and retirement of inactive agents.

A four-week pilot

**Week 1.** Collect repetitive tasks and select one low-risk workflow: a brief, policy search, or public-source analysis. Record manual time and quality.

**Week 2.** Assign an owner, connect read-only data, and prepare 30–50 test examples. Define prohibited data and actions.

**Week 3.** Give a small group access. The agent prepares output, while users compare it with manual work and label material edits.

**Week 4.** Count accepted outputs, hours, spending, and errors. If gates pass, register the agent and set a review date. If not, retire it and preserve the reason.

Build the next agent only after a shared template, logs, and retirement process exist. That is slower than the first demo but faster than untangling dozens of ownerless automations six months later.

Management takeaway

The Hallam case suggests that employee access to agent creation can reduce the IT queue and compress some processes from days to minutes. The result, however, rests on allocated time, training, shared data, and a governed platform.

Do not start with a contest to build the most agents. Start with a one-item registry: owner, data, permissions, tests, metrics, budget, and review date. Vnutrik has already delivered a cabinet full of tools; maturity begins with deciding which drawers remain locked.