Virtual services + New
| Service | Protocol | Status | Calls |
|---|---|---|---|
| customer-api | HTTP | Replaying | 12,480 |
| payments-mq | IBM MQ | Replaying | 3,204 |
| core-ledger | JDBC | Recording | 128 |
| partner-sftp | SFTP | Passthrough | 47 |
| fx-rates-ws | WebSocket | Replaying | 9,655 |
GienTech
Service Agentification
AI agents create, maintain, and manage virtual services — and generate the realistic data to fill them — so automated testing never waits on a real system.
What it is
Service virtualization, in one line.
A stand-in for a system your application depends on. It answers on the real protocol, with real recorded responses — so your app connects exactly as it would in production and cannot tell the difference.
What it stands in for
Not just APIs — everything your app talks to.
Real systems don't only speak HTTP. They queue messages, move files, answer queries, and hold connections open. A stand-in has to speak whatever the real one speaks.
Why testing needs it
Test as if it's already there.
Every one of these is a reason a test cycle stalls today.
Start before it existsBuild and test against systems another team hasn't finished.
No environment queuesNo booking a slot on the shared test system everyone fights over.
Same result every runDeterministic responses. A red build means a real defect, not a flaky environment.
Test what you can't triggerTimeouts, partner outages, the once-a-year error — on demand.
Safe by defaultNo real customer data. No accidental live transactions in test.
Lower costNo per-call fees to third-party and partner systems during testing.
So why isn't everyone doing it
The idea is proven. The practice is expensive.
Service virtualization has been around for years. Adoption stalls for three reasons — and none of them are about whether it works.
01Build it yourselfTeams write and maintain their own stubs — often with dedicated headcount.
02Buy a toolCommercial platforms are licensed per seat and per environment.
03Find the skillsEither route needs specialists most teams do not have.
Pain point 01 · Build it yourself
Teams hire developers to write fake systems.
The stub becomes a second codebase — one that ships no product value, yet needs the same care as the one that does.
Extra
Headcount on stubsEngineers writing and maintaining mocks instead of building the product.Per team
Rebuilt every timeEach squad writes its own stub for the same backend. Nothing is shared.Silent
DriftThe real API changes; the stub doesn't. Tests keep passing against a system that no longer exists.Pain point 02 · Buy a tool
Commercial tools solve it — at a price, and a gate.
Licence
Priced per seat, per environmentCost scales with the number of people and pipelines you want to unblock — exactly the wrong direction.
Skills
A specialist tool needs specialistsDedicated training and certification. The people who know it become a bottleneck, and when they move on the knowledge goes too.
Assets
Mocks locked in a proprietary repositoryCan't diff them, can't review them in a pull request, can't roll one back like code.
Weight
Its own infrastructure to run and maintainServers, databases, upgrades — a platform to look after before it delivers a single test.
Pain point 03 · The data
Even with the tool, you still need the data.
A virtual service is only as useful as what it returns. Getting realistic test data is its own project.
Production data is off limitsReal customer records can't be copied into test — and shouldn't be.
Hand-written data is thinThree sample customers won't exercise the paths that break in production.
Nothing stays consistentThe same customer has a different name in three systems, so end-to-end tests fail for the wrong reason.
Refresh is manualEvery schema change means someone regenerates the fixtures by hand.
Service Agentification
Take the expertise out, put an agent in.
The gaps aren't in what service virtualization does. They're in what it costs to operate. That is what an agent removes.
How the gaps close
Each pain point, answered.
Headcount
Nobody writes stubs by handThe agent creates the virtual service from a plain-language description, a spec, or captured traffic.
Skills
Anyone on the team can askNo product training, no certification, no specialist gate. If you can describe what you need, you can build it.
Data
Test data generates itselfOne example becomes hundreds of lifelike records, consistent across every field, sensitive values masked.
Assets
Recordings are plain filesCommit them to git, review them in a pull request, roll a bad one back. They behave like code because they are.
Create & manage
Build it from whatever data you have.
"Read the transaction logs for this API call and build virtual services for it."
GienTech Agent
Done — built from 4,812 logged transactions:
- Found 6 operations on customer-api
- Inferred the request and response shapes
- Created recordings, including 3 error paths
- Masked account numbers and names
Data synthesis
Grounded — never invented.
The agent learns the shape of your data from what you already have, so what it generates is realistic rather than plausible-looking.
Infers the real schemaStructure learned from your recordings, logs, and specs — not guesswork.
Keeps observed patternsFormats, code lists, and value ranges seen in real traffic.
Consistent entitiesThe same customer stays the same customer across every field and every service.
Masks sensitive fieldsNo real PII leaves your systems.
Edge & error casesDrawn from patterns that actually occurred — dormant, expired, rejected.
Replay-readyDrops straight into the virtual service, correctly formatted for its protocol.
The big picture
How it all fits together.
The product
Every virtual service, at a glance.
gientech · operator dashboard
Virtual servicesRecordingsData StudioMatch explainerAudit
The product
Generate a dataset as you watch.
gientech · data studio
Virtual servicesRecordingsData StudioMatch explainerAudit
Synthesize — customer-api Generating…
1 example → 100 records · engine: AI (local) · consistent entities
John DoeActive · SG-014
Jane DoeActive · SG-002
Sam DoeActive · SG-118
Alex DoeDormant · SG-041
Pat DoeOnboarding · SG-007
Robin DoeActive · SG-233
The product
Every change, on the record.
gientech · audit
Virtual servicesRecordingsData StudioMatch explainerAudit
Audit trail
09:41:02agentcreated virtual service customer-api
09:41:18agentgenerated 200 synthetic customer records
09:44:37j.doeswitched customer-api to replay
10:02:11ci-runnerreplayed 1,284 requests · 0 misses
10:15:56s.doeedited recording GET /customers/{cif}
Where this goes next
Built today. Next on the roadmap.
Shipped
Virtualization, agent authoring, data synthesis15 protocols, agent-created services, synthetic datasets, match explainer, audit trail.
Next
Drift detectionSample the real API on a schedule and flag the moment a response shape changes.
Next
Targeted re-recordRefresh only the operations that moved, and regenerate the data to match.
Next
Import your API docs, get a working serviceHand it a spec — messaging and SOAP alongside the REST import that works today — and the agent builds the service and its data.
GienTech Service Agentification
Ask for it. Test against it.
01Agents build the servicesNo stub developers, no specialist tooling.
02Agents generate the dataRealistic, consistent, masked, replay-ready.
03Automation never waitsA dependable test target, every build.