What I’m Exploring and Building Now

I’m developing Build Good AI as an advisory and product practice for organizations trying to decide what AI is actually worth doing.

The business is still being validated. I’m not presenting a large service catalog as though every offer has already been proven in the market. The current work is much more focused: helping a company examine one meaningful workflow, understand what is getting in the way, and make an evidence-backed decision about what should happen next.

That may lead to an AI product or workflow. It may lead to deterministic automation, better information, a clearer process, or a decision not to build anything yet.

I’m working through how to make that judgment valuable as a standalone outcome. A company should be able to leave with a defensible proceed, refine, or stop decision without being pushed into an implementation engagement simply because implementation is easier to sell.

I’m also defining what responsible follow-on work would require: representative evidence, a named business owner, clear success and stop conditions, an evaluation plan, explicit human authority, and enough operating readiness to support the system after the initial build.

I’m building a Discovery Engine that helps someone map how work actually happens before deciding what technology belongs in it.

The prototype asks about the current workflow, information sources, decisions, exceptions, consequences, available evidence, and the boundary between what a system may help with and what people must continue to own.

The output is a provisional opportunity map. It separates what the user said from what the system inferred, preserves unknowns, and identifies what still needs to be established. It does not generate a fake readiness score or pretend to have completed a technical assessment from a questionnaire.

That boundary is intentional.

I’m exploring whether an interactive tool can make useful product and operating judgment more accessible without creating false certainty. The full result appears before any optional contact request because the tool should provide value before asking for something in return.

The current version is a local prototype, not a production diagnostic. I’m using it to test the reasoning, interaction model, evidence structure, and experience of moving from a messy problem to a clearer decision.

I’m also working on a practical approach to AI performance and governance.

A lot of governance work begins with policies. A lot of performance work begins with model metrics. Both matter, but neither tells the whole story.

I want to understand what the system is doing inside the work:

• Is it producing a technically plausible output?
• Is the output useful for the decision someone needs to make?
• What happens when it is wrong?
• Which errors cause the most harm?
• Are people correcting the same problem repeatedly?
• Is the system reducing work or moving it somewhere less visible?
• Does anyone know who owns the result, the exception, and the next change?

The emerging offer begins with one use case and one decision brief. It separates what is working, what is assumed, what remains unknown, and what needs attention. From there, the work can move through assessment, operating design, enablement, and periodic review.

The client would continue to own its systems, controls, decisions, operations, and compliance obligations. Build Good AI’s role would be to help make the evidence, boundaries, responsibilities, and review process clear enough to manage.

I’m not trying to create a governance layer that makes useful work impossible. I’m trying to make sure autonomy is earned, consequential decisions still have owners, and systems remain understandable after the novelty wears off.

I’m evaluating a possible client-side program leadership role for a benefits intelligence pilot.

The proposed role is deliberately separate from technical delivery. It would involve translating real benefits workflows into testable requirements, coordinating pilot participants, defining acceptance criteria, maintaining decision and risk records, evaluating vendor performance, and helping the client decide whether to proceed, revise, expand, replace, defer, or stop.

That engagement has not been accepted as active delivery. Authority, scope, commercial terms, protections, and pilot commitments still need to be resolved.

I’m interested in the model because companies often need someone representing the business decision while a vendor represents the build. A successful pilot should not be defined by whether software appeared. It should show whether the product improved the intended work, handled uncertainty appropriately, preserved source evidence, and created enough value to justify the next investment.

I’m applying the same scrutiny to Build Good AI that I would apply to a client’s product.

That includes developing and testing the offer architecture, pricing assumptions, qualification rules, delivery boundaries, client responsibilities, security and legal gates, and the economics of providing the work responsibly.

I’m also building the website, visual system, reusable components, case studies, and editorial portfolio that explain the business without overstating what has been proven.

The website and design system are working assets, not simply brand exercises. I’m using React, TypeScript, structured design tokens, reusable components, generative development tools, and coding agents to see how a small company can create a coherent product and content system without separating strategy, design, copy, and implementation into isolated projects.

Some of it is polished. Some of it is still being tested. Nothing has earned the right to be called traction until people pay for it, use it, and receive a measurable result.

I’m actively using AI to research, write, analyze, prototype, code, compare alternatives, structure evidence, and build working experiences.

I’m not using it as a machine that produces finished answers on command. I’m using it as working material.

That means exploring:

• Coding agents that can move between product reasoning, interface design, implementation, and verification
• Agent instructions and reusable skills that make behavior more consistent without pretending instructions are permissions
• Model Context Protocol connections that allow systems to retrieve information and act through approved tools
• Persistent context and organizational memory that reduce repeated searching without erasing provenance
• Structured outputs that preserve assumptions, uncertainty, and evidence status
• Evaluation systems that measure task quality, workflow outcomes, human correction, and business results separately
• Confidence thresholds, review states, appeals, and escalation paths
• Deterministic controls for calculations, permissions, redaction, and other work that should not depend on model interpretation
• AI observability that connects technical performance to what people and the business actually experience
• Interfaces that help people inspect, correct, and own the result

I am also paying close attention to where these systems fail.

A model can produce a strong answer from incomplete context. An agent can follow instructions and still have more access than the task requires. A prototype can work beautifully with seeded data and fall apart when the real workflow introduces exceptions. A summary can sound authoritative after the evidence supporting it has disappeared.

Those are not side concerns. They shape the product.

The questions I keep coming back to are operational.

What context does a system need to do useful work?

Which parts of the process should be exact, and which require interpretation?

How much autonomy has the system earned?

Can someone trace the result back to its evidence?

What happens when the system encounters something it has never seen?

Who owns the decision when the answer affects a customer, employee, artist, contract, or financial record?

How does the organization learn from corrections rather than making the same correction forever?

And can the people responsible for the work understand, operate, and improve the system without becoming permanently dependent on whoever built the first version?

That is how I’m engaging with emerging technology. I’m close enough to the tools to understand what has changed, skeptical enough to test what has not, and interested in the full system required to turn a new capability into better work.