Unthought.

Artificial Intelligence

Readiness assessment, implementation, and the evaluation work that makes both survivable.

Most stalled AI programs did not fail at the model. They failed at the data that was never structured, the workflow nobody had written down, the integration surface that did not exist, and the unanswered question of what happens when the system is confidently wrong. We assess those first, in writing, because they are what determine whether an implementation is possible at all.

The work divides into two tiers that are usually sequential. The first is a scoped readiness assessment: a review of the systems, data, workflows, integration surface, and risk exposure that any AI implementation would have to sit on top of. Its deliverable is a written roadmap — a document, not a presentation — intended to hold up in front of a board, an investor, or a diligence process.

The second tier is implementation: assistants, document processing, in-product language-model features, and agentic workflows, together with the evaluation and guardrail work that determines whether they can be operated, not merely demonstrated.

The assessment exists as a separate engagement because the honest answer is sometimes that the organization should not build the thing it came to discuss, or should not build it yet. That answer is worth paying for and it is difficult to reach credibly from inside an implementation contract. An assessment that can only conclude 'yes, and here is the quote' is not an assessment.

Evaluation is designed before the feature is built, not after it misbehaves. That means a written set of cases the system must handle, a definition of what a wrong answer looks like in this specific domain, and a measurement that runs repeatedly rather than once. A model change upstream can alter behavior without any change to the code, which makes a standing evaluation the only thing that will notice.

Failure behavior is specified in the same breath as success behavior. What the system does when it is uncertain, when the upstream service is unavailable, when the input is adversarial, and when the output would be acted on automatically — these are design decisions, and leaving them undecided is itself a decision, usually a bad one.

Where a system's output affects a person's money, health, legal position, or employment, we build for human review by default and treat full automation as a case that has to be argued, not assumed. This constrains what we will build, and that constraint is the point.

Nothing here is sold on the premise that the technology is inevitable. The useful question is narrower and more answerable: which specific, repeated, currently-manual judgement in this organization is a good candidate, what would it cost to be wrong, and what would have to be true for it to work.

Exclusions

What Artificial Intelligence does not take on.

  • Fully automated decisions affecting a person's money, health, legal position, or employment, without human review.
  • Training foundation models. We build on existing models instead of producing them.
  • Synthetic media of real people — voices, likenesses, or generated endorsements.