About

Why Progeny exists

Too many AI initiatives begin with the technology and end as disconnected demonstrations. The capability is real, the demo works, and then it meets an actual approval chain, an access policy, a system of record, and a team that already has a way of doing things.

Progeny was created to start at the other end: with operational value, and to carry the work through architecture, implementation, governance, and adoption. The measure of an engagement is not whether something was built. It is whether the work moves differently afterward.

Leadership

Two disciplines, one conversation.

Enterprise AI work comes apart between functions — executive intent, operational reality, security constraint, and engineering practice. Progeny covers that span with two people instead of a relay: one trained to establish what an organization is actually dealing with, one who builds the systems the answer has to run on.

Peter Norman

Founder and Principal Solutions Architect

Peter leads architecture and delivery at Progeny. His recent work has concentrated on a specific problem: the point where an AI-generated record stops being a draft and becomes a decision a person is accountable for. He has built that control point for two separate healthcare platforms under HIPAA constraints, and advises on architecture and scope for an agency measuring how AI systems represent its clients.

Working at both ends is deliberate. The decisions that determine whether an AI initiative reaches production are usually made early, in rooms where the business context and the technical constraints are being discussed at the same time. Progeny is set up so those decisions get senior attention rather than being escalated later.

Rebecca Norman

Head of Growth and Strategic Partnerships

Rebecca leads growth and partnerships at Progeny. She holds an M.Ed. in counseling and passed the National Counselor Examination — training built almost entirely around finding out what someone is actually dealing with before proposing anything. Discovery is that same skill pointed at an organization.

AI initiatives rarely stall on the model. They stall on an approval chain nobody mapped, a team that was never asked, a process three people understand and none of them have written down. Surfacing those is Rebecca’s part of the work, and it happens in the first conversation rather than in month three, when they turn into a delay.

That conversation is a qualification, not a pitch. Part of the job is saying plainly when what is being described is not an AI problem — or not one worth the cost of solving.

Recent work

The same problem, three times.

Client names are withheld under NDA. What the three have in common is the point where a system's output becomes a decision someone has to stand behind — reliably the hardest part to build, and the part most often left until last.

Agency · AI visibility measurement

Advisory and delivery on the same engagement.

A public affairs agency measuring how AI assistants describe its clients, scored against each client's own approved messaging.

What we delivered

Architecture audit delivered as a tiered document — the decision at the top, the technical detail underneath
Phased roadmap against an approved engagement baseline, with what fell in and out of scope settled in writing
Fixed automated scoring that was marking valid content as failures, so the numbers reaching clients meant something
Made silent model failures visible, instead of letting a run finish looking like a success

Healthcare · AI clinical documentation

The signature layer for an AI clinical documentation platform.

An ambient scribe can draft a clinical note. It has no standing until a clinician attests to it — and the attestation is worth nothing unless what was signed can be proven later.

What we delivered

Canonical hashing of the signed payload, so a record's integrity can be verified after the fact
Signed originals held immutable, corrections handled as addenda rather than edits in place
Exportable verification packets: what was signed, by whom, under which attestation
Clinical model traffic moved onto BAA-covered infrastructure, with data residency written into the compliance record

Healthcare · Clinical intake

One provider signature closing an entire clinical set.

A multi-location clinic moving intake, assessment, and orders off paper and three legacy applications.

What we delivered

Versioned attestation capturing the provider's credentials as they stood at signing
Step-up two-factor authentication at the point of signature, so the person signing is the person credentialed to sign
Provider order capture — medication, physical therapy, durable medical equipment — defined in the form schema rather than hand-built one form at a time
Answers frozen onto the signed record, so what the provider signed cannot drift afterward

Internal tools

We run our own business on these.

Two systems we built for ourselves. The arguments we make to clients — approval gates, audit trails, keeping model access contained — are ones we had to live with first.

Customer intelligence

Catalyst

Pulls leads in from connected sources, reads what the interaction history says about each one, and drafts the response. Every action it recommends waits on a person.

Design decisions

Event-sourced — an append-only record of what happened, with every view built from it. Any state the system reports traces back to the events that produced it
Exactly one module may call a model, enforced by an architecture rule in CI so model access cannot quietly spread
Approval by default; autonomy is earned per action type rather than switched on across the board
Tenant isolation enforced at the database row level rather than in application code

Lead generation

Outbound agents

Six agents that research target organizations, qualify them, draft an approach, and manage follow-up. It runs our own pipeline, which means we are the first to notice when it gets something wrong.

Design decisions

Three autonomy modes — draft only, approve each send, or fully autonomous — chosen per campaign rather than assumed
Suppression and opt-out enforced inside the system, not left to the judgement of whoever is operating it
Every agent run recorded with its input, output, token cost, and duration, so behavior can be audited and spend attributed
Prompts kept as versioned files outside the code, so changing what the system says is reviewed like any other change

How we engage

What working with us is actually like.

Direct access

You work with the people doing the work. There is no separate team that appears after the proposal is signed.

Plain assessment

If a workflow is not a good candidate, or the value is smaller than expected, you hear it early — while it is still cheap to change course.

Handover as a deliverable

Systems come with documentation, evaluation criteria, and a named ownership path. Dependency on us is not the business model.

Start with a conversation about the work.

The most useful first discussion is about a specific workflow — how it runs, who touches it, and what it costs. We will tell you honestly whether we are the right people for it.

Discuss an AI Opportunity Explore Our Approach