Building one agent is a demo. Running a hundred is a factory.
AgentFactory is how DataGOL gets agents out of the pilot and into the business. They run on data that's already cleaned up and agreed on, behind one control screen that decides what every agent is allowed to see, do, and change.
Agents get assembled here rather than written from scratch. You start from one that already does a similar job, point it at your data, tell it your rules, and test it on real work before anyone relies on it.
start from agents that already work
rules written once, reused everywhere
tested on real cases before going live
runs in chat, in your product, or in the background
AI Firewall
✓ every change an agent makes is recorded
✓ you choose what each agent can see and change
✓ answers come from one agreed set of numbers
✓ anything an agent did can be traced back
The gap
Everyone has agent pilots. Almost nobody has agents in production.
An agent that can only look things up is easy to demo and easy to ignore. The moment it needs to change something — update a record, approve a claim, adjust a price — the questions start. What did it use to decide? Who said it could? What exactly did it change? Can we undo it? Most companies can't answer, so the pilot never goes live.
“Agents that look things up are impressive. Agents that change things are useful — and that's exactly where every company gets stuck.”
How an agent gets built
Six steps. Every agent goes through all of them.
The order matters, so the steps are numbered. Each one makes the next easier — which is why the tenth agent takes a fraction of the work of the first.
01
Get the data ready
We connect the systems your business actually runs on and clean the data up, so an agent is working from something you'd be comfortable showing your board.
connects to the tools you already use
organized and checked automatically
every number traceable to its source
02
Agree on what things mean
Decide once what counts as a customer and how revenue is calculated. Every agent then uses the same definition, so nobody argues about whose number is right.
03
Build the agent
Start from an agent that already does a similar job, rather than from a blank page. Most of the work is telling it about your business, not writing it from scratch.
04
Set the rules
Choose what this agent is allowed to look at and what it's allowed to change. Bigger decisions can require a person to approve them first.
05
Test it on real work
Before it goes live, we run it against real cases from your business and show you where it got things right and where it didn't.
06
Watch it and improve it
Once it's running, you can see what it's doing. When something goes wrong, the fix carries over to every agent that comes after it.
What you get today
Five things, running on your data.
Not a roadmap. This is what you actually end up with, in this order.
01
Your data, ready to use
We connect the systems you already run and turn them into one clean, trustworthy set of numbers an agent can work from.
DATAOS
02
One agreed set of definitions
What a customer is, how revenue is counted, who's allowed to see what — held in one place, along with a record of every decision an agent made.
CONTEXTDB
03
A control screen for your agents
See what every agent is doing, set what it can look at and change, and switch one off without touching anyone's account.
LENS
04
Agents that already work
Start from agents built for jobs you already do, then adjust them to your data, your rules, and who has to approve what.
AGENTFACTORY
05
Our engineers on your team
We build alongside your people rather than through a ticket queue. You keep the system, and your team knows how it works.
FDE
Where people meet it
One platform. Several front doors.
The same governed agents show up wherever the work already happens, so nobody has to be talked into opening a new tool.
01
Ask in chat
Your team asks questions in plain language and gets answers from your own numbers, not a guess.
02
Inside your product
Dashboards and agents embedded in the app your customers already log into, under your branding.
03
In the systems you use
Agents reach your CRM, ERP, and support tools through connections you approve, and write back where you allow it.
04
On a schedule
Work that should just happen — overnight checks, weekly reporting, alerts — runs without anyone asking for it.
05
Through an API
Your developers call the same governed agents from your own code, with the same rules applied.
06
Talk to it
Ask out loud and get an answer back in real time — for people on the road, on the floor, or with their hands full.
07
Draw the workflow
Lay out a multi-step process on a canvas and have agents run it, without anyone writing code to connect the steps.
08
Build it yourself
HarnessX, our agent framework, is open source and free to use. Your engineers can start this afternoon without talking to us first.
How it lands
From one connected source to a working floor.
Timings from projects we've run. The order matters more than the dates — an agent never gets to change anything before everyone agrees what the numbers mean.
DAY 1
Connect one system
We plug into one system you already use and put an agent in front of it, answering real questions you can check for yourself.
WEEK 2
Agree on the numbers
Your definitions move into one place. Two teams stop reporting two different revenue figures, and the agent stops guessing.
WEEK 6
Let it do the work
The first agent starts making real changes — inside limits you set, with approvals where you want them, and a record of everything it does.
ONGOING
Add more agents
Each new agent reuses the same data, definitions, and rules — so it takes less time and money than the one before it.
What changes
Agents that your auditor, your CISO, and your CFO can all live with.
Accountable
Every change an agent makes is recorded: what it changed, when, and on whose authority.
Controlled
Agents can only see and change what you allow, using their own access rather than an employee's.
Consistent
Every agent works from the same definitions, so two of them can't give you different answers.
Cheaper each time
The work done for the first agent gets reused by the tenth, so cost per agent falls instead of rising.
Behind the scenes
For the person who's going to ask how.
Everything above, in the language your data and platform team will use. Same system, different register — bring this part out when the engineers join the call. Skip it entirely if they don't.
The decision record
WHAT LENS WRITES ON EVERY RUN
An observability tool watches calls. A data tool watches tables. Lens records the decision — six fields, written every time an agent acts. Fields 02 and 05 are the ones nothing else on the market holds.
01Inputs read
Which facts, at which version of the context.
02Authority
The policy in force for that agent, at that moment.
03Rationale
The reasoning committed to before acting.
04Action taken
Tool, arguments, target system.
05Write emitted
The state change, diffable against what was there before.
06Outcome
What happened downstream, linked back to the run.
Store all six and "why did it do that?" is a query. Store fewer and it's an investigation.
Getting the data ready
DATAOS
Medallion architecture
Bronze holds raw, immutable source data. Silver conforms and deduplicates it. Gold is modeled to the business. Each tier is materialized and independently testable, so a bad transform doesn't silently poison everything downstream.
Golden layer
The gold tier, modeled to your business entities. It's the only surface agents and BI are pointed at — nothing queries raw tables directly.
Change data capture
Log-based replication from source systems, so changes land continuously rather than in nightly full loads. Agents act on current state, not last night's snapshot.
Lineage
Column-level provenance captured at write time rather than reconstructed after the fact. Every field traces back to its source, its transform, and the job run that produced it.
Artifacts
Pipelines, models, tests, and deployments are versioned artifacts in source control with a review workflow — not configuration clicked together in a UI that nobody can diff.
Agreeing what things mean
CONTEXTDB
Ontology
The typed graph of entities, relationships, and attributes — what a customer, contract, or claim is in your business, and how they connect. Agents reason over this rather than guessing from table names.
Semantic layer
Metric and dimension definitions resolved at query time, so "net revenue" compiles identically whether it's asked for by a dashboard, an API call, or an agent.
Bitemporality
Two clocks: valid time (when the fact was true in the business) and system time (when we recorded it). This is what lets you reconstruct exactly what an agent knew at the moment it decided — the difference between an audit and an argument.
Governance
Row-level, column-level, and masking policy bound to the data and enforced in the semantic layer, so it holds regardless of which tool or agent is asking.
Policy-as-code
Access and behavior rules stored as versioned, reviewable code moving through the same pull-request workflow as everything else. Skills are policy: reusable, tested, and promoted rather than pasted into prompts.
Setting the rules
LENS
Control plane
A runtime registry of every agent, tool, and connection, sitting in the path of every call. See → understand → control → improve, with the AI Firewall as the enforcement point.
Scoped write access
Read and write permissions granted per tool and per method, not per user. An agent can read the whole CRM and write to exactly one object, with approval gates on the calls that warrant them.
Agent tokens
Non-human identities with their own credentials, scopes, expiry, and revocation — decoupled from employee accounts, so revoking an agent doesn't mean disabling a person.
MCP
Model Context Protocol, the standard for connecting agents to tools and data. Every MCP server is registered, permissioned, and traced through Lens rather than wired up ad hoc by whoever built the agent.
Evals
Versioned suites of real cases run before promotion, with regression gates. Failures return the full trace — prompt, tool call, result, write — not just a score.
Building and running agents
AGENTFACTORY
Assembly, not authoring
An agent is composed from a workflow template, a set of versioned skills, registered tools, and the context layers beneath it. Almost nothing is written from scratch per agent.
Promotion path
Every agent moves dev → eval → production through the same gate. Nothing reaches production without a passing eval run and an owner attached.
Decision record
Each run writes back what the agent decided, what it changed, which policy authorized it, and what context it used. That record lives in ContextDB alongside the data itself.
Human-in-the-loop
Approval routing on the actions you flag as high-impact, with the request, the proposed change, and the supporting context presented together so the reviewer isn't rubber-stamping.
Forward-deployed delivery
Our engineers build inside your environment and your repos, and hand over a system your team can operate — not a black box with a support contract.
The open-source harness
HARNESSX · MIT
pip install harnessx
A Python SDK, open source under MIT. Typed functions become tools from their hints and docstrings; MCP servers are discovered and validated the same way local tools are.
Permissions in the code path
Every tool carries ALLOW, ASK, or DENY, with iteration limits and a per-run cost budget. The permission model your engineers write against is the same one Lens enforces in production.
Durable runs
Run state, tool results, and pending approvals persist to SQLite or Postgres, so a run survives an application restart and resumes where it stopped rather than starting over.
Model fallback
Retry policies with capped waits, and a fallback chain to another model or provider on transient failure — configuration, not a rewrite.
Flight recorder
Capture a run's model and tool boundaries, export a portable .hx incident file, and inspect the timeline offline without spending a single new model call.
Orchestration and knowledge
HARNESSX · AGENTX
Delegation
A lead agent hands focused work to specialist agents with their own tools and context, and their results return to the parent. Research, analyze, and write are three agents, not one overloaded prompt.
Skills
Task-specific instructions loaded only when needed, so the context window holds what the current step requires instead of everything the agent might ever do.
OKF knowledge
Open Knowledge Format bundles searched with BM25F. Matching concepts come back with their provenance attached, and links lead to related facts when one answer isn't enough.
Typed decisions
The companion Jev SDK handles routing, classification, and answer review as typed decisions inside the workflow — structured outputs rather than parsed prose.
Extensions
Tools, hooks, and state packaged as a unit and installed into any agent. This is how a capability built for one customer becomes available to the next.
Interfaces and developer surfaces
APPX · AGENTX
Real-time voice sessions
Low-latency speech in and out over a live session, with the same permissions, policy checks, and decision record applied as any other channel. Voice is a front door, not a separate product with its own rules.
Visual workflow canvas
Compose multi-step processes visually, with every node bound to a registered tool or agent — so what gets drawn is what gets governed, rather than a diagram that drifts from the running system.
ADK / SDK
For teams building on top of DataGOL rather than inside it: the same agent contract, permissions, and tracing, in your own codebase and on your own release cycle.
Embeddable widgets
Drop a conversational assistant into any page or app under scoped credentials, so an embedded agent can never exceed what its host is entitled to see.
Published endpoints
Expose a finished agent as an addressable endpoint your own systems can call, with the same gateway, budget, and audit path in front of it.
Models and spend
LENS · AI GATEWAY
Any model, your keys
One gateway in front of every provider. Bring your own keys and contracts rather than renting ours, and swap models without touching agent code.
Automatic failover
Provider outages and rate limits route to a fallback instead of taking your agents down with them.
Budgets and limits
Hard spend ceilings per agent, per tenant, and per user, with cost attributed by model, agent, user, tenant, and step — so an expensive agent is a line item, not a surprise.
Policy checks
Every call passes the policy layer on the way out. This is the AI Firewall: the single interception point in the path of all model and tool traffic.
Watching it run
LENS · OBSERVABILITY
Traces
Full waterfall per run — prompt, tool call, result, write — with the provenance spine showing which policy authorized each step and under whose identity.
Drift monitoring
Flags agents whose behavior changes without a config change — a reasoning path growing from 9 to 23 tool calls over a week is caught before the invoice is.
Skills Doctor
Names the cause of a cost or quality regression and proposes the prompt or skill change, rather than leaving you to read traces until you find it.
Adoption analytics
Which agents are actually used, by whom, and how often — the number that tells you whether the deployment worked.
Identity, isolation and audit
LENS · GOVERN
Enterprise identity
SSO-backed human identity, with agent identities registered separately so attribution never collapses into "someone's service account."
Tenant isolation
Strict separation of data, context, and credentials per tenant — built for multi-tenant SaaS, not retrofitted onto a single-customer install.
Guardrails
Content, PII, and behavior checks applied in the path rather than asked for in a prompt, so they hold when the model doesn't cooperate.
Immutable audit
An append-only record of configuration changes, grants, denials, and writes. A denial is recorded as carefully as an action — the agent tried, it had no grant, Lens refused on the agent's token.
Memory and context
CONTEXTDB · MEMORY
Durable memory
Memory that persists across runs and across agents, held in the substrate rather than stuffed back into a prompt each time.
Knowledgebases
Unstructured sources — documents, transcripts, tickets — indexed against the same ontology as the structured data, so retrieval and reporting agree.
Replay
Re-run any decision against the context and policy that were in force at the time, not today's. This is what bitemporality buys you.
Portability
Context, skills, and policy are exportable configuration. The system is yours to operate, not a managed black box you rent access to.
The product surfaces
WHAT THESE ARE CALLED INTERNALLY
AgentX
The agent runtime — where skills, tools, and guardrails are defined and where agents actually execute.
AppX
The application surface — customer-facing data apps and embedded analytics shipped inside your own product.
OrchX
The orchestration agent — automates building the governed golden layer, including extracting business logic from existing docs and transcripts.
Dave
The conversational analyst agent — asks and answers questions against the governed layer in plain language.
HarnessX
The open-source Python agent framework underneath it all. MIT licensed, public on GitHub, usable without DataGOL.
// Confirm the five descriptions above, plus voice and the workflow canvas, before this page goes anywhere — see the note in chat.
Our belief
Agents don't fail because the model is weak. They fail because nothing underneath them knows what the business means.