# Tenex: expert services, agents, and controlled delivery

Research date: 2026-10-09. Report style: ASD-STE100 Simplified Technical English.

Tenex helps companies find useful AI work, select tools, change processes, and deliver software.
Its main offer combines human experts, existing AI tools, custom agents, and internal process software.
The public evidence supports a services business with reusable methods and tools.
The evidence does not establish a general, autonomous AI employee product.
[S01: website](https://www.tenex.co/), [S02: transformation service](https://www.tenex.co/ai-transformation).

The closest match to our Chief AI Officer concept is Tenex’s discovery and execution service.
Its most useful technical lesson is explicit context, code checks, and evidence before greater autonomy.
These are research conclusions, not measured product results.

## Scope and evidence

This report covers the company at **tenex.co**, led by Alex Lieberman and Arman Hezarkhani.
The company differs from the cybersecurity company at tenex.ai.
Lieberman provides distribution expertise. Hezarkhani provides technical expertise.
Their biographies and founder account support this division.
[S04: company identity](https://www.tenex.co/about-us), [S27: founder lessons](https://alexlieberman.com/what-i-have-learned-building-in-ai/).

The archive contains 34 sources from the company, its founder, GitHub, and original publishers.
Company descriptions remain company claims unless this report states otherwise.
Public files confirm a skill artifact, but we did not execute that skill or test MetaHarness.
The two job pages contain only application shells. The podcast review covers the publisher’s written account, not the complete audio.
The [source index](sources/README.md), [manifest](sources/manifest.json), and [search log](sources/search-log.md) record these limits.

## The complete customer process

A sponsor defines the business need. Tenex surveys employees and executives, then interviews the relevant people.
The team identifies process problems and establishes baseline measures.
The customer receives an adoption report, a technical appendix, and a proposed execution plan.
Execution can use a purchased tool, Tenex intellectual property, or custom software.
Workshops and process changes help employees use the result.
This process is the company’s stated service, not a reviewed customer deployment.
[S02: service process](https://www.tenex.co/ai-transformation).

![Tenex service data flow](diagrams/data-flow.png)

The diagram combines the service description with the founder’s pilot method.
It shows responsibilities and records, not verified software interfaces.
[S26: pilot method](https://alexlieberman.com/ai-pilot/).

The strategy playbook adds a useful discovery mechanism.
Interviewers ask for actual task steps, exceptions, frequency, cost, and business impact.
Claude Code then uses the survey and interview files to propose opportunities with employee evidence.
The team challenges these proposals before a Notion roadmap records owners and dependencies.
The playbook favors a purchased tool for a generic task and custom code where the workflow needs it.
It favors controlled workflows with a few AI steps over unrestricted agents.
[S11: strategy playbook](https://www.tenex.co/playbooks/build-an-ai-strategy-that-works).

The founder’s pilot method starts with one measure, a baseline, and a target.
The workflow owner defines success, costs, forbidden actions, and conditions to expand, revise, or stop.
Readiness covers data access, support, adoption, authority, and controls.
Greater scope and autonomy depend on results.
The examples illustrate the method. They do not prove customer returns.
[S26: pilot specification](https://alexlieberman.com/ai-pilot/).

## What the customer buys

| Offer | Customer receives | Important limit |
| --- | --- | --- |
| AI transformation | Discovery, tool selection, process changes, and employee instruction | Human experts still own the service |
| Software delivery | A technical product manager and forward deployed engineers | The customer supplies priorities and reviews progress |
| Custom agents | A workflow designed for the customer’s systems and rules | No standard public product specification establishes all agent capabilities |
| Public playbooks | Repeatable methods, prompts, and selected artifacts | A tutorial does not prove a production deployment |

The service pages support the first three rows. The library supports the final row.
[S02: transformation](https://www.tenex.co/ai-transformation), [S03: software service](https://www.tenex.co/ai-engineering), [S06: playbooks](https://www.tenex.co/playbooks).

Tenex says it charges clients for story points and pays its team for completed story points.
Tenex defines those points. The customer selects ticket priorities and can use an existing tracker with a shared Slack channel.
This unit measures delivered work. A story point does not measure revenue, profit, or customer satisfaction.
The public page does not disclose point prices, acceptance disputes, warranty terms, or how teams calibrate points.
[S03: commercial model](https://www.tenex.co/ai-engineering).

The original interview publication describes technical strategists whose incentives depend on customer retention.
That account suggests a counterweight to incentives for output volume. This is an architecture and business inference.
The same account describes large future engineer pay. It does not provide audited payroll evidence.
[S21: Latent Space founder interview account](https://www.latent.space/p/10x-ai-engineers-with-1m-salaries).

## MetaHarness: the software delivery system

**Company claim.** MetaHarness coordinates engineers and agents through a Git project record.
Markdown separates current facts, product intent, technical plans, history, client material, scratch notes, and protected archives.
Startup hooks assemble context. Versioned skills provide task methods.
The CLI checks references and completion evidence. Tracker writes require a preview and a separate apply step.
Sync changes machine metadata blocks. Human prose remains editable.
Tenex OS derives project health from the record.
[S07: internal architecture](https://www.tenex.co/blog/building-an-ai-native-sdlc).

![MetaHarness architecture](diagrams/architecture.png)

The diagram shows responsibilities, not service boundaries.
Conflict resolution, storage details, and the full skill registry remain undisclosed.
The [archived article](sources/S07-metaharness.txt) gives further detail.

## The custom agent design method

The founder’s recent sprint guide provides a separate agent blueprint.
A data gateway connects tools. Context includes a data map, tested query recipes, entity aliases, a glossary, and known traps.
A router selects skills. A constitution and autonomy levels constrain behavior.
Events or schedules can start work. The demonstration must show an approval enforced through the gateway and a completed action loop.
[S34: founder sprint guide](https://alexlieberman.com/enterprise-ai-agent-sprint/).

The guide explicitly uses synthetic data and emulators for prototypes.
Private connectors can remain mocked. No production credentials belong in the prototype.
Thus, a successful demonstration does not establish safe production integration.
The guide does not name the gateway product or publish the router, listener, permission, or recovery implementations.
Its proposed return measures include labor capacity, financial effects, and error costs.
It distinguishes released capacity from cash savings.
[S34: prototype conditions](https://alexlieberman.com/enterprise-ai-agent-sprint/).

These details support a conceptual design, not a complete Tenex platform specification.
MetaHarness governs software delivery. The sprint guide describes how a team could design a customer agent.
Public evidence does not show that both use one runtime or one shared business memory.

## Company knowledge and reusable skills

An employee article describes Slack, Notion, and other connectors as sources of company context.
Anthony Dupont-Cinko used repeated questions and output review to define a content task, then saved the method as a skill.
The article also describes **Field Notes**, which gathers client and project context into Notion.
These are disclosed internal workflows. Their accuracy, coverage, and access controls remain untested here.
[S09: employee account](https://www.tenex.co/blog/claude-skill-interview-method).

The article links a public **tribal-knowledge** repository.
The inspected skill checks available sources, asks for the desired result, follows evidence, verifies claims, and reports gaps.
Its trace reference uses repeated questions, exceptions, reversals, named experts, workarounds, warnings, and stale documents as search leads.
Every proposed finding needs a source link. Sensitive material needs separate care.
This artifact confirms a concrete instruction method. It does not confirm reliable execution or the complete MetaHarness implementation.
[S31: repository](https://github.com/TenexTony/tribal-knowledge), [S32: skill](https://raw.githubusercontent.com/TenexTony/tribal-knowledge/main/SKILL.md), [S33: trace patterns](https://raw.githubusercontent.com/TenexTony/tribal-knowledge/main/references/traces.md).

There are distinct forms of context in these accounts: project records, client summaries, and task skills.
Our inference is that a shared model context needs clear scope and authority for each form.
The sources do not establish a single universal memory system.

## Evaluations and recovery

The evaluation guide tests traces with cases, graders, and versioned runs.
Code checks verify actions. Model graders assess answers or tool sequences. Human labels check model judges.
A failure becomes a case after sensitive data removal and a definition of correct behavior.
The team reproduces the failure, changes the agent, and runs the full dataset.
[S08: evaluation guide](https://www.tenex.co/blog/eval-driven-development).

![Evaluation and regression cycle](diagrams/evaluation-cycle.png)

This diagram shows the published method.
The guide defers historical tool state and safe offline writes to later articles.
Its refund scores are examples, not benchmarks.
[S08: evaluation limits](https://www.tenex.co/blog/eval-driven-development).

The introductory playbook adds a comparison against the plain model and cases withheld during refinement.
Those checks can reveal a skill with little benefit or a system tuned only to visible tests.
We reviewed selected written sections, not its embedded episode.
[S14: first evaluation](https://www.tenex.co/playbooks/due-diligence-your-first-agent-eval).

## A concrete internal workflow: customer health

Tenex describes on-demand, scheduled, and active customer health workflows.
The diagram shows the tools and human action boundary.
[S12: customer health playbook](https://www.tenex.co/playbooks/monitor-customer-health-3-ai-agents).

![Customer health data and action flow](diagrams/customer-health.png)

Delivery points and health scores provide directional signals.
The playbook gives no labeled churn dataset or controlled retention result.
The method prepares human action from scheduled reports.
[S12: signal and review limits](https://www.tenex.co/playbooks/monitor-customer-health-3-ai-agents).

## Controls for employee-built software

The **Citizen SDLC** article addresses a separate problem: a useful employee prototype can become unsafe shared software.
Its six stages are idea, intake, triage, provision, build, and operate or change.
AI proposes classifications. Code applies policy. Humans handle exceptions.
The process assigns an owner, checks duplicates, and provides approved infrastructure before code reaches production.
[S10: Citizen SDLC](https://www.tenex.co/blog/citizen-sdlc).

The reported controls cover templates, merge checks, runtime identity, isolated infrastructure, and edit history.
Destructive schema changes, new dependencies, and changes to constraints need human review.
The second direct user triggers the full lifecycle.
The article reserves regulated systems of record and external applications for professional engineers.
Its anonymous investment-firm account reports roughly nine automatic triage decisions per ten requests.
No independent audit, denominator, or observation period accompanies that result.
Broad throughput figures elsewhere in the article lack enough method detail for a comparison.
The described controls are company claims, not controls tested by this research.
[S10: deployment boundaries](https://www.tenex.co/blog/citizen-sdlc).

The founder’s deployment checklist adds least privilege, prompt injection defenses, traces, cost limits, rollback, and a stop control.
It requires a named owner and cost per completed task, with review and maintenance costs.
This is advice. It does not prove that every Tenex engagement applies every control.
[S25: deployment checklist](https://alexlieberman.com/enterprise-ai-deployment-checklist/).

## Evidence map and commercial uncertainty

| Claim | Evidence type | Assessment |
| --- | --- | --- |
| Tenex combines discovery and delivery | Company claim, S01–S03 | Clear service description. No reviewed engagement contract |
| MetaHarness provides controlled project state | Company claim, S07 | Detailed mechanism. No public executable or runtime test |
| A public knowledge skill exists | Public artifact, S31–S33 | Files inspected. Execution and accuracy untested |
| Customer health reports lead to drafts | Company claim, S12 | Concrete tool path and human review boundary. No impact test |
| Employee apps have enforced controls | Company claim, S10 | Anonymous deployment account. Controls not independently tested |
| Point incentives improve delivery | Company claim and publisher account, S03/S21 | Incentive design is clear. Causal effect remains unverified |
| Vercel and Tenex have a partnership | Founder announcement, S28 | Stated scope covers customer services and events. Partner-side confirmation was not found |
| Tenex has strong financial returns | Unresolved | No audited revenue, margins, or controlled customer return study found |

Lieberman describes Tenex as bootstrapped and identifies midmarket companies as an attractive customer group.
He says free roadmaps and workshops create sales opportunities.
These are founder statements, not audited financial facts.
[S19: founder company page](https://alexlieberman.com/tenex/), [S27: founder lessons](https://alexlieberman.com/what-i-have-learned-building-in-ai/).

The founder’s Vercel announcement covers services for Vercel customers and joint events.
It does not establish a shared technical runtime.
[S28: partnership scope](https://alexlieberman.com/announcing-our-partnership-with-vercel/).

The prototype sales anecdote ends with another prospect conversation. The founder explicitly says no agreement was signed yet.
Treat the account as evidence of a sales approach, not a closed deal or a customer return.
[S20: sales anecdote](https://alexlieberman.com/win-deals/).

Attribution needs care.
The library’s sales-agent story concerns Vercel and Drew Bredvick. Its savings and team changes are not Tenex customer results.
The evaluation cookbook concerns Ash Tilawat at Gauntlet AI. The prototype playbook concerns Alex Berger at Bolt.
[S17: Vercel account](https://www.tenex.co/playbooks/build-an-ai-agent-that-replaces-90-of-your-sales-team), [S16: Gauntlet method](https://www.tenex.co/playbooks/how-to-test-your-ai-5-stage-framework-for-evaluating-agents-llms), [S18: Bolt method](https://www.tenex.co/playbooks/show-then-tell-how-high-fidelity-prototypes-collapse-product-alignment).

The current Anthropic webinar page redirects to Claude and does not name Tenex in the captured text.
An older search excerpt cannot establish the current relationship. The archive preserves the page and redirect.
[S30: current webinar page](https://www.anthropic.com/webinars/claude-for-life-sciences).

## Lessons for our Chief AI Officer concept

These are research recommendations based on the evidence above.
They do not add requirements to our product plan.

| Lesson | Proposed use | Condition or tradeoff |
| --- | --- | --- |
| Discover work through actual examples | Ask about recent tasks, exceptions, and failed attempts | Interviews need evidence. Opinions alone can misstate value |
| Preserve an opportunity record | Link the problem, owner, baseline, proposed action, and acceptance rule | Keep facts separate from proposals |
| Make knowledge claims traceable | Preserve source links and report missing evidence | A source link alone cannot prove that a claim is correct |
| Control writes through code | Preview consequential changes and apply explicit permission rules | A persuasive prompt must not replace an authorization check |
| Earn autonomy through results | Start with reports or drafts, then expand after tests and measured use | Good demos do not prove production safety |
| Derive status from evidence | Use completed actions, tests, and owner decisions | Evidence of activity can still fail to show business value |
| Retain human responsibility | Route exceptions to a named owner with the relevant context | Escalation load can limit scale |

Tenex offers a useful services reference for the discovery stage of our concept.
It also shows how much expert judgment a production workflow can need.
The main unresolved product question is whether those expert decisions can become reliable, bounded software behavior for smaller companies.

The [Hone report](../hone/README.md) focuses on persistent agents that pursue business outcomes.
The [TextQL report](../textql/README.md) focuses on analysis and reusable business knowledge.
Tenex adds a human service model and an explicit software delivery process.
These categories describe the reviewed evidence. They do not rank the companies or their results.

## Questions that could change the conclusion

1. Which parts of discovery and process design require a Tenex expert in each engagement?
2. Which MetaHarness components can customers license or operate independently?
3. How do point calibration, acceptance rules, and retention incentives prevent low-value output?
4. Which production agents use the published gateway and skill-router design?
5. How do those agents preserve permissions, recover after tool failures, and reject stale context?
6. How does Tenex test writes against historical system state without real external effects?
7. What customer-authored evidence shows net savings after expert labor, infrastructure, review, and maintenance?

## Sources and diagram files

Start with the internal architecture article, Citizen SDLC, evaluation guide, strategy playbook, and recent founder sprint guide.
Their links appear beside the relevant sections above.
The [source index](sources/README.md) links every capture and records authors, dates, and review limits.

| Diagram | Editable definition | Vector export |
| --- | --- | --- |
| Service data flow | [Mermaid](diagrams/data-flow.mmd) | [SVG](diagrams/data-flow.svg) |
| MetaHarness architecture | [Mermaid](diagrams/architecture.mmd) | [SVG](diagrams/architecture.svg) |
| Evaluation cycle | [Mermaid](diagrams/evaluation-cycle.mmd) | [SVG](diagrams/evaluation-cycle.svg) |
| Customer health | [Mermaid](diagrams/customer-health.mmd) | [SVG](diagrams/customer-health.svg) |

The [render script](diagrams/render.py) creates the image and diagram exports.