I've been building Oracle to make it easier for coding agents to create developer tools.
One thing I keep coming back to is how much work goes into building the application around a relatively simple utility. A tool might only need to query an API, inspect some records, or modify a configuration file. Giving it a usable interface introduces another collection of decisions: navigation, layout, loading states, error handling, editing, and feedback.
These are familiar problems with familiar solutions. Yet each generated application can end up solving them differently.
I'd like to reach a point where I can describe the functionality I need and have an agent build a usable application around it, following established interaction patterns.
Oracle is my attempt to provide that foundation. I'm also exploring how agent skills and an MCP-based cookbook could teach agents to use it consistently.
Building a Reusable Application Toolkit
Oracle combines reusable UI components with the infrastructure needed to build interactive applications.
The repository currently contains two implementations:
- TypeScript: React and Electron libraries for desktop applications, including an application shell, UI controls, logging, IPC, and supporting infrastructure.
- Kotlin: Compose Multiplatform libraries with desktop and mobile presentation components, shared runtime contracts, and platform adapters.
I wanted both because the right language depends on the tool I'm building.
TypeScript works well for web-oriented utilities and tools that integrate with JavaScript SDKs. Kotlin is useful for mobile applications, JVM integrations, and applications with more involved concurrency requirements.
My goal is to keep the interaction patterns recognizable across both implementations while allowing each to follow its platform's conventions.
A developer should be able to choose the technology that fits the problem and still get a familiar application experience.
Defining the Boundary
One architectural decision has been particularly important: deciding what belongs in Oracle and what belongs in the application.
I've kept Oracle focused on presentation and human interaction. The consuming application owns its business logic, persistence, authentication, and external effects.
Consider a tool that displays records from an API.
Oracle can provide a collection view with selection controls, sorting, and pagination-related presentation. The application supplies the records, handles data requests, and decides what happens when the user selects an item.
The same boundary applies to editing.
The TypeScript toolkit includes retained draft sessions, structured editors, observation contracts, action feedback, and collection controls. These provide common ways to preserve edits, communicate stale data, and display the outcome of operations.
The application still decides whether an action is authorized, whether a retry is safe, and what constitutes success.
I like this separation because it gives Oracle a reasonably stable responsibility. The interaction patterns can be reused across tools that have completely different underlying behavior.
It also creates a useful constraint for agent-generated applications. The agent needs to understand where the toolkit's responsibilities end and where its own implementation begins.
Components Are Only Part of the Problem
Having reusable components available doesn't guarantee that an agent will use them well.
Suppose I ask an agent to build a utility that displays a large collection of records, allows me to select one, and provides an editable detail view.
There are several decisions involved:
- Which layout best supports browsing and editing?
- Which Oracle components should display the collection?
- Where should the selected record state live?
- How should unsaved edits behave when changing the selection?
- How should loading, failure, and stale data appear?
- Which responsibilities should remain with the application's data layer?
An agent can make all these decisions independently. The results may vary depending on its familiarity with Oracle and the examples available in its context.
That variability is what I want to investigate.
I see two useful kinds of guidance here. One helps an agent design the application. The other helps it implement specific behaviors using Oracle.
I'm considering agent skills for the first and an MCP-based cookbook for the second.
A Cookbook MCP for Implementation Patterns
The cookbook would expose reusable implementation recipes through an MCP server.
An agent could describe the behavior it needs and retrieve guidance that matches the task.
For example, an illustrative request might look like this:
{
"behavior": "Display records with selection and editable details",
"constraints": {
"largeDataset": true,
"retainEdits": true
}
}
The cookbook could respond with relevant Oracle components, implementation examples, API contracts, and architectural considerations.
For this request, I would want the recipe to explain how to connect a collection view to a detail editor, where to retain selection state, and how to preserve edits through an application-owned draft session.
It should also explain the choices involved.
For instance, a collection might load all records into memory or request pages as the user navigates. Both approaches can support a similar interface, but they have different implications for performance, state management, and data freshness.
The cookbook would help the agent select an appropriate pattern and implement it using the available APIs.
What the MCP Interface Might Look Like
I'm considering a small set of operations:
find_recipes: Find implementation patterns matching a requested behavior.get_recipe: Retrieve a complete recipe with examples and constraints.get_component_contract: Retrieve the supported API for an Oracle component.compare_patterns: Compare implementation approaches and their tradeoffs.
These are proposed operations. They haven't been implemented as Oracle APIs.
I like the idea of keeping the interface small. Most of the value should come from the quality of the recipes and how easily an agent can find the relevant one.
The cookbook would also give me a way to organize implementation knowledge around behaviors instead of individual components.
An agent building a collection-and-detail workflow probably cares more about preserving selection and edits than about reading the documentation for every component independently.
A recipe can bring those pieces together.
Why Use MCP?
MCP provides a convenient way for agents to retrieve implementation guidance when they need it.
An agent working on collection navigation could request the relevant recipe. Later, when implementing a structured editor, it could retrieve another.
This keeps detailed API knowledge available without loading the entire cookbook into the agent's initial context.
I also see an opportunity for version-aware documentation.
If the cookbook knows which Oracle version the application uses, it could return compatible examples and component contracts. That would become especially valuable as the toolkit evolves.
There is a maintenance cost, though. Recipes need to stay synchronized with the implementation.
Outdated guidance could cause an agent to generate code against APIs that have changed. A cookbook that confidently recommends the wrong method would be an impressive way to make development slower.
I'd want some form of verification connecting recipes to actual source code, examples, or tests.
That's an important part of the design I haven't settled yet.
Agent Skills for Application Design
The cookbook would help with implementation details. I also want agents to have a consistent approach to designing the application itself.
I think agent skills are a good fit for this.
An Oracle application-design skill could guide an agent through questions such as:
- What is the primary workflow?
- What information needs to remain visible?
- How should users navigate between records or views?
- Which actions need confirmation or feedback?
- How should the interface communicate loading, errors, and stale data?
- What state should survive navigation?
These decisions shape the application before the agent starts choosing components.
For a collection-and-detail utility, the skill might recommend keeping the current selection visible while editing a record. It could also suggest retaining unsaved changes when navigating between views.
Once the agent has selected an interaction pattern, it can retrieve the corresponding cookbook recipe.
The workflow I'm considering is:
User describes the utility
|
v
Application-design skill
|
v
Select interaction patterns
|
v
Retrieve Oracle cookbook recipes
|
v
Implement application functionality
|
v
Build and verify
This gives each part of the guidance a clear responsibility.
The design skill establishes how the application should behave. The cookbook provides the implementation details.
I also see value in a separate implementation skill covering project creation, dependencies, integration with application services, and verification.
These could eventually form a workflow where the agent moves from a short functional description to a working application using established Oracle conventions.
That's the idea I want to test.
Keeping TypeScript and Kotlin Consistent
Supporting two implementations raises an interesting question: what should consistency mean across different frameworks?
I've been leaning toward consistency in interaction behavior.
TypeScript applications naturally use React components, callbacks, and promises. Kotlin applications use Compose, coroutines, and interfaces.
Trying to make their APIs identical would introduce awkward abstractions. I want each implementation to feel natural in its own ecosystem.
The shared behavior matters more to me.
For example, both implementations should have understandable conventions for:
- Showing stale or outdated observations.
- Preserving edits while navigating.
- Reporting the progress and outcome of operations.
- Presenting errors and uncertain results.
- Handling selection and collection navigation.
This has implications for the cookbook.
I could describe a pattern such as retained editing once, then provide separate TypeScript and Kotlin implementations.
The shared recipe would explain the interaction semantics. The language-specific examples would explain how to implement them.
I think that could be a useful way to keep both implementations aligned, although I'd start with recipes tied closely to the current code.
Maintaining semantic consistency across two evolving libraries is already a challenge. Adding generated documentation on top of that deserves some caution.
How I Want to Test It
There are two hypotheses I want to evaluate.
The first is that Oracle reduces the amount of repeated application work required to build developer tools.
The second is that agent skills and a cookbook MCP help agents use Oracle more consistently.
These need separate experiments because the toolkit and the agent guidance solve different problems.
Experiment 1: Building With and Without Oracle
I'd start by asking an agent to build equivalent utilities using two approaches:
- Building the application with its usual libraries and custom implementation.
- Building the same application using Oracle.
I'd compare implementation effort, generated code, corrections, and functional correctness.
I'm particularly interested in how much code is devoted to common application behavior.
If Oracle is doing its job, I would expect less repeated implementation of navigation, editing, state presentation, and action feedback.
That remains a hypothesis until I run the comparison.
Experiment 2: Documentation Versus Skills and MCP
The second experiment would keep Oracle constant and change the guidance available to the agent.
I'd compare:
- An agent using ordinary Oracle documentation.
- An agent using the application-design skill and cookbook MCP.
Both would receive the same application requirements.
I'd look at API misuse, corrections, implementation consistency, and whether the generated application follows the intended interaction patterns.
One behavior I'm especially curious about is how frequently the agent creates custom components when Oracle already provides something suitable.
If that happens, the cause could be missing documentation, poor recipe discovery, or a genuine limitation in the available components.
Those are different problems, and the experiment should help identify which one I'm dealing with.
I would also want to record cookbook tool calls and the guidance returned. That would make it easier to distinguish problems with recipe discovery from problems with how the agent applies the retrieved information.
What Comes Next
Oracle already contains much of the presentation and interaction infrastructure I want to reuse across developer tools.
The next step is to make that infrastructure easier for coding agents to discover and apply.
I'm inclined to start with a small cookbook covering a few common behaviors: collection navigation, retained editing, loading and error states, and action feedback.
Those recipes would give me something concrete to test before expanding the interface or building more elaborate design skills.
The question I'm most interested in is how much guidance an agent actually needs to use a toolkit consistently.
A good recipe might be enough for a narrowly defined task. A more complex application might benefit from design guidance that connects several recipes into a coherent workflow.
I don't know where that boundary falls yet.
Finding it could be just as useful as building the cookbook itself.