Begin with a capability the product needs
“Add AI” is not a product requirement. “Find a document when the user remembers its subject but not its name” is. So is “extract reliable fields from mixed files,” “explain which sources support an answer,” or “plan a bounded sequence of tool calls and stop when approval is required.”
A specific task makes architecture discussable. It exposes what must be correct, how quickly the result should arrive, what data the system may access, and which failure is worse: a missing answer, an invented answer, or an action taken too far.
Sometimes the best implementation is not a model. Rules, search, direct manipulation, or a clearer information structure may be faster and more dependable. Applied AI earns its place when the task genuinely benefits from language, perception, retrieval, or adaptive reasoning.
Retrieval-augmented generation is mostly a context system
Retrieval-augmented generation, or RAG, gives a model selected material at the moment it answers. The model does not become the source of truth; it becomes a reader and synthesiser of sources the system can identify.
Retrieval quality depends on work outside the prompt: extraction, chunk boundaries, metadata, embeddings, lexical matching, ranking, filtering, and the decision to return no result when the evidence is weak. A polished answer cannot rescue the wrong context.
Citations complete the loop. They let a person inspect the evidence, correct the system, and continue working from the original material. In Curator, semantic file search and chat both lead back to files rather than hiding them behind a response.
Agentic systems need explicit boundaries
An agent can choose tools, sequence work, inspect results, and revise a plan. That flexibility is useful when a task cannot be expressed as one deterministic request. It also creates more ways for a system to misunderstand scope or continue after the useful part is finished.
A sound agentic design defines the available tools, the data each tool can reach, the maximum work allowed, and the moments that require human approval. Tool results should be structured enough to inspect, and side effects should be distinguishable from read-only reasoning.
The interface should show what is happening at the level a person needs to judge it. A raw stream of internal thoughts is neither necessary nor useful. A clear plan, current action, source, and approval boundary usually are.
Local inference changes the privacy and latency trade-off
Running embeddings or language models on a person’s device can keep sensitive content out of a hosted pipeline and make some interactions available offline. It can also remove network latency from frequent, bounded tasks.
Local does not automatically mean fast, private, or efficient. Model size, memory pressure, background indexing, battery use, storage growth, and update behaviour are part of the product. Good local AI is designed within a resource budget and stays responsive on the hardware it claims to support.
Hosted and local models can coexist when the choice is visible. The important properties are a legible data path, purposeful defaults, and no surprise transfer of content.
Evaluate the system people use, not only the model
Model benchmarks answer useful research questions, but product quality lives at the system boundary. For retrieval, test whether representative queries return the right evidence. For extraction, measure field-level accuracy on the file types that matter. For agents, record task completion, unnecessary tool calls, approval handling, and recovery after a tool fails.
Performance belongs in the same evaluation. Time to first useful result, memory use, energy cost, index size, and degraded behaviour on slower hardware affect whether a capability remains useful outside a demo.
Evaluation sets should contain ordinary cases, difficult cases, and cases where the system should decline. A trustworthy product is allowed to know when its evidence is insufficient.
Keep people oriented and in control
AI changes how a result is produced; it does not remove the need for clear product behaviour. People still need to know what will happen, which material was used, what changed, and how to undo or correct it.
Bleural’s product rule is simple: intelligence should make the task easier to complete without making the software harder to trust. That means visible sources, restrained automation, honest uncertainty, and conventional controls where conventional controls remain better.