AI Products and Developer Tools
AI-native applications, copilots, agents, model platforms and developer tools share one product obligation: turn variable model behaviour into work a person or organisation can understand, evaluate and operate.
- AI Product UX
- Developer tools
- Evaluation
- Product engineering
The category contains several different products
Tcules has worked on twelve products involving copilots, AI-native tools, AI-powered features or AI integration. The work combines AI Product UX, product modelling, coded demonstrations and software engineering according to the product condition.
Each row describes a product shape and the central decision it creates. These product shapes are not maturity levels.
| Product shape | Central product decision |
|---|---|
Copilot inside existing software | What context, objects and actions may the copilot access without weakening the system of record? |
Bounded agent | Which tools and steps may run, where does the person intervene and how is partial work recovered? |
Vertical AI product | Which domain decision does the product own, and which authority remains with a qualified person? |
Model or orchestration platform | How can developers compare, configure and operate capability without losing provider and version detail? |
Evaluation or observability product | Which scenarios, traces, failures and costs help a team decide whether behaviour is acceptable? |
AI coding or creation tool | How does speed remain compatible with review, provenance, tests and maintainable output? |
Four tensions shape the product model
- 01
Abstraction and inspectability
The interface can remove repeated setup while preserving access to provider, model, source, cost, latency, version, permission and failure information where a technical or accountable user needs it.
- 02
Open-ended intent and durable state
Language helps a person express an objective. Structured objects make a workflow comparable, editable, reusable and observable. An AI-native product needs to decide what conversation creates and what persists after the response.
- 03
Rapid capability and a stable promise
Models and providers change faster than product commitments. The team must decide which capabilities, quality thresholds and failure behaviours become part of its own contract.
- 04
Automation and authority
Retrieval, recommendation, preparation and execution carry different consequences. An agent crossing tools needs scoped permission, step state, stop conditions, idempotency and recovery.
- 01
Use case
The use case defines evaluation and the authority required.
- 02
User intent
Intent enters the workflow with the permitted context needed to interpret the request.
- 03
Context and permission
Authorised context limits what the product can use and what operations it may support.
- 04
Model or workflow version
Intent and permitted context enter a versioned model workflow.
- 05
Tool and authorised operation
Tools create explicit step states and affected objects.
- 06
Run and step state
The product keeps enough state to make the work recoverable and observable.
- 07
Output or proposed action
The workflow produces an output or proposed action before commitment.
- 08
Evidence
Evidence qualifies an output before human or automated commitment.
- 09
Human decision
A person remains involved where the product condition requires human authority.
- 10
Evaluation case
Evaluation cases connect the use case to representative and difficult scenarios.
Current AI product work
- 01
ConnectX
ConnectXConnectX shows a conversational request becoming a bounded, persistent energy workspace through eight defined scenarios and a coded demonstration.
- 02
BuildTwin
BuildTwinBuildTwin shows evidence, correction and escalation designed around an engineer who remains accountable for AI quality-control results.
- 03
Eden AI
Eden AIEden AI shows template, AI-assisted and from-scratch creation entering one developer workflow without erasing their differences.
- 04
Novus Insights
Novus InsightsNovus Insights shows generated questionnaire material remaining under researcher review and approval.
Product, experience and engineering meet at evaluation
Tcules can define user work, product objects, model role, tools, interaction, evidence, human authority and recovery, then carry that contract into coded prototypes or software. Evaluation connects these responsibilities.
Evaluation tests whether the complete product behaviour supports the intended decision across representative and difficult scenarios.
The NIST AI Risk Management Framework (opens in a new tab) provides a broader risk-management reference. Tcules uses authoritative guidance to inform the work, not as evidence of certification or a client's controls.
Start with one decision, one model-influenced workflow and one failure the product must recover from. That is enough to establish the operating model before capability expands.
Discuss an AI product
Start with one decision, one model-influenced workflow and one failure the product must recover from.