About

I build the agents. Then I run them.

Twenty-five years of enterprise operations, an automation program that produced $7.8M a year, and four agent systems in production right now.

Founder

Brian E. Smith

Founder, AIGenic Technologies, LLC · Van Alstyne, Texas

Brian E. Smith, founder of AIGenic Technologies

How the agents get built

  • Multi-step orchestration with explicit state, retry, and resumable runs
  • Tool access scoped to the minimum the task requires
  • Retrieval over governed corpora: deduplicated, provenance-tagged, citable
  • Transparent weighted scoring; every recommendation shows its work
  • Human approval gates set by consequence, not model confidence
  • Full decision logging: inputs, evidence, breakdown, outcome
  • Backtesting against historical outcomes before anything ships

Also

  • Enterprise RPA at scale
    Automation Anywhere 360 Cloud, Control Room, AARI, IQ Bot, queue architectures, mainframe and document-management integration, IAM for automated identities
  • PMP · held 2007 to 2023
    Advanced Program Management, Stanford · 2010
    ITIL · PM3 Level 2

Most people selling AI arrived in the last eighteen months. I came from the other direction. Twenty-five years building and running the systems AI now has to plug into, then five years running an enterprise automation program that had to prove its savings to a CFO every quarter.

I built that program's Center of Excellence from nothing: intake, prioritization, governance, build standards, change control, compliance, value reporting. Then I led the team that ran it. $7.8M in annual savings and business value, with processing times cut by as much as 60%. Most of that work was in insurance and healthcare, which teaches you things unregulated industries don't: that an audit trail isn't optional, that "the model was confident" is not a defense, and that a control nobody can follow is worse than no control at all.

The last stretch of it was spent evaluating whether agentic automation was ready for production. It was. Almost nobody was packaging it for companies below enterprise scale. So I left to do that.

Building an agent is the easy half. The hard half is the exception queue, the audit trail, and the person who owns it on Monday.

What I build now isn't prototypes for a deck. Four systems are described below in enough detail that you can judge the engineering rather than take my word for it.

Outside the work: cars, history, theology, chess, and more science fiction than is strictly defensible. I ran amateur circuit racing and still take cars to track days, and the track habit turns out to be relevant. Fast is easy for one lap. Fast, repeatable, and still on track at the end of the session is a different discipline, and it's the same one that separates a working automation from a demo.

What I've built

Four agent systems, described by what they do.

Client names are withheld. The architecture isn't. That's the part worth evaluating, and the part that tells you whether the same approach survives in your business.

Feasibility & valuation agent

A land-development feasibility agent, calibrated against closed deals

A regional developer was screening land acquisitions on instinct and a spreadsheet. The agent handles the first pass. It mines public county GIS for parcel geometry and ownership, models subdivision feasibility, and identifies which utility is legally obligated to serve each parcel. The off-market target lists come from criteria no listing service exposes: large acreage, deeded decades ago, owner's mailing address in another city, near-zero improvement value.

Then we backtested it, and the model was wrong. Run against two completed subdivisions and thirty-three closed lot sales, the first version overstated road take by up to 1.9×, per-lot development cost by 3.35×, and absorption pace by 1.44×. Uncorrected, it would have killed good deals and approved bad ones with equal confidence.

None of that surfaces from a demo. It surfaced because the model was made to predict outcomes that had already happened, where being wrong was checkable.

How it's built

  • Ingest from public GIS services with pagination and schema discovery
  • Off-market targeting as a parameterized spatial and attribute query
  • Geometric plat simulation rather than naive contiguity
  • Pricing and absorption curves regression-fitted to closed transactions
  • Backtest harness reporting model-versus-actual error per component
1.9×
Road take overstated
3.35×
Per-lot cost overstated
1.44×
Absorption overstated
33
Closed sales fitted against
Signal-driven targeting

Four companies to call this morning, not five hundred

Built for a consultancy whose real problem was engagement, not a shortage of prospects. They had no defensible way to decide who to call today. The system watches a defined market for the events that create an opening, then each morning returns a handful worth a call: who to ring, why now, and a specific opening line written for that person's role.

Every score opens up: the reasoning, what changed at the company in the last twelve months, how their marketing compares to competitors, and the buying group with a recommended order of approach. Three buttons feed back into the ranking, so it gets more accurate as it's used.

How it's built

  • Automated company analysis producing a structured profile
  • Trigger detection across leadership change, hiring pattern, and funding
  • Weighted scoring with per-factor contribution exposed in the UI
  • Role-aware message generation grounded in that company's evidence
  • Feedback capture that adjusts subsequent ranking
  • Demonstrated on labeled synthetic data before any real prospect touched it
Multi-agent workflow & compliance

A multi-agent discovery, scoring, and compliance-documentation platform

A daily agent run that discovers candidates from defined sources, deduplicates against everything already known, verifies each is still live, scores it against a published weighted model with a recommendation floor, and persists the full breakdown as one record: score by factor, fit, material gaps, sources, and the reason for recommending or excluding. Every rejection the user writes becomes a derived screening rule, so the system's judgment converges on theirs.

The guardrails are written into the spec, not left to inference. The system never submits, never contacts a third party, and never files anything with the agency it documents for. It produces evidence; a human decides and acts. Stating that in the documentation is the only way a boundary survives a rebuild.

How it's built

  • React 19 on the Next App Router, compiled to a Cloudflare Worker
  • Drizzle ORM over Cloudflare D1, typed schema with ordered migrations
  • Schema validation on every persistence boundary
  • Evidence stored as structured JSON, so one record reconstructs a decision
  • Idempotent status reconciliation; history is never overwritten
  • No trackers, no client-side secrets, write APIs behind an access policy
  • Architecture, data dictionary, workflow rules, and security posture ship with the code
Governed knowledge base

An evidence database built so the citations survive scrutiny

A research corpus of 610 verified sources across six subjects, in Postgres, with the discipline that separates a defensible knowledge base from "we loaded your documents into a vector store." Deduplication runs by publication identifier, then DOI, then normalized URL, because the same paper reaches you three different ways.

Each source carries relation labels so evidence about a parent compound, a class, or a structural analog is never silently read as direct evidence. That distinction is invisible in a naive retrieval setup, and it's exactly what makes a generated summary wrong in a way nobody catches. Writes go through one sanctioned function that enforces the rules; integrity was confirmed three independent ways.

The same architecture underlies any internal assistant that has to answer from your own content and be trusted when it does.

How it's built

  • Postgres with a dedicated schema and row-level security enabled
  • Single ingest function enforcing dedup precedence and relation labeling
  • Provenance tagging separating audited from unaudited records
  • Full SQL rebuild of the corpus from scratch in under a minute
  • Written verification report listing what was checked and what passed
610
Verified sources
0
Duplicate IDs or URLs
99/99
Files passing checksum
3
Methods confirming counts

The pattern

What those four have in common.

Different domains, same engineering. This is what your project gets too.

  • Nothing scores without showing its work. A number you can't interrogate gets ignored the second time it's wrong.
  • Validated against something real before anyone trusts it. Backtested against closed transactions, checked against a known-good audit, or run beside the existing process. Confidence is not evidence.
  • Corrections train the system. "Not this one" becomes a rule, not a note nobody reads.
  • Hard boundaries written into the spec. What the agent may never do is documented, not left to the model's judgment in the moment.
  • Documented well enough to be rebuilt without me. Any of these could be handed to another engineer tomorrow.

Track record

Where the operating judgment comes from.

  • Founder, AI & agentic automation
    AIGenic Technologies, LLC·2026 to present

    Designing, building, and operating agent systems for small and midsize companies.

  • Automation & AI program leadership
    National insurance carrier·2021 to 2026

    Founded and ran the Automation Center of Excellence. $7.8M in annual savings and business value, up to 60% faster processing. Owned the scalability and resilience roadmap for a ten-VM cloud automation estate, and drove the evaluation that moved it from traditional RPA toward agentic automation. Latterly led delivery and QA across five concurrent automation workstreams in underwriting, claims, licensing, and Medicare.

  • Program & portfolio delivery
    Global IT services firms·2014 to 2021

    A $94M cost-reduction portfolio for a national hospital system. 21 legacy applications retired across 16 hospitals for $7.5M annual savings against a $2.9M budget. $10M+ in client savings identified through operating-model analysis. This is where the ROI modeling and benefits-realization discipline came from.

  • Systems, network, infrastructure & security
    Credit data · global telecom · online travel · enterprise infrastructure

    Progressive engineering, managed-services, and delivery roles across complex enterprise environments. Twenty-odd years of watching systems fail in production is why the agents get guardrails, monitoring, and an exception queue before they get a demo.

Industries

  • Insurance: underwriting, claims, licensing, Medicare
  • Healthcare: hospital systems, clinical imaging, research infrastructure
  • Financial services: credit and data environments
  • Public sector: school districts, municipal data centers
  • Technology & telecom: managed services and enterprise IT

What I don't do

Train foundation models. Sell you a platform license. Run a research project on your budget. If the honest answer is an off-the-shelf tool at $40 a month, an integration, or fixing the process before automating it, that's the answer you'll get.

The name

Why a hummingbird.

Small, precise, disproportionately capable. A hummingbird holds position in moving air and changes direction instantly, because of control, not mass. The companies I work with aren't going to out-hire a Fortune 500 AI department, and they don't need to.

"AIGenic" combines AI with genic, meaning producing or generating. Systems that produce something, not systems that demonstrate something.

Have a process worth talking about?

Thirty minutes, no pitch deck. Tell me what's costing you the most and I'll give you an honest read on whether this is worth pursuing.