<?xml version="1.0" encoding="UTF-8"?>
    <rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/">
      <channel>
        <title>Duong (Young) Dang — Field Notes</title>
        <link>https://example.com/</link>
        <description>Writing on AI agents, RAG, MQTT, MCP, workflow automation, and industrial software.</description>
        <language>en-us</language>
        
      <item>
        <title>Building a RAG System for an Internal Knowledge Base</title>
        <link>https://example.com/blog/rag-for-internal-knowledge/</link>
        <guid isPermaLink="true">https://example.com/blog/rag-for-internal-knowledge/</guid>
        <pubDate>Wed, 30 Sep 2026 00:00:00 GMT</pubDate>
        <description>What it takes to turn scattered internal information into a useful, grounded assistant—and why retrieval quality matters more than a clever prompt.</description>
        <author>Duong (Young) Dang</author>
        <content:encoded><![CDATA[An internal knowledge assistant sounds simple at first: index a collection of documents, connect a language model, and ask questions. The hard part is not making the model answer. It is helping it answer from the right information, show its limits, and stay useful as the knowledge changes.

I recently built a retrieval-augmented generation (RAG) system for an internal knowledge base. I’m keeping the source material and implementation details private, but the work reinforced a few design principles that apply to many RAG projects.

## Retrieval is part of the product

When an answer is wrong, it is tempting to focus immediately on the model. Often the real issue appears earlier: the relevant passage was never retrieved, a document was split in an unhelpful way, or the source itself was stale. Good responses depend on a chain of decisions—ingestion, parsing, chunking, indexing, retrieval, and generation.

That means a RAG system should be evaluated as a pipeline. Keep a small set of representative questions, record which sources should support each answer, and test changes against that set. A prompt tweak that improves one example but makes retrieval harder to inspect may not be a real improvement.

## Make evidence visible

People need a way to judge an answer. Showing the documents or passages used to form a response helps users verify claims and find more context. If the system cannot find relevant evidence, it should say so instead of filling the gap with a confident guess.

This is especially important for internal knowledge: the assistant is navigating information created for different audiences, at different times, and with different assumptions. Clear citations and sensible abstention help preserve trust.

## Start with the work people do

The best first version is not necessarily the one with the most connectors or the biggest model. Start by learning what people repeatedly search for, where that information lives, and what a useful answer should look like. Then build the smallest workflow that can help—and measure whether it actually saves effort.

RAG is not a magic layer placed on top of documents. It is a search and interaction experience, with a language model in the middle. Treating it that way makes the system easier to improve and easier for people to trust.]]></content:encoded>
      </item>
      <item>
        <title>Giving AI a Safe, Structured Way to Work with MQTT Devices</title>
        <link>https://example.com/blog/mqtt-mcp-for-connected-devices/</link>
        <guid isPermaLink="true">https://example.com/blog/mqtt-mcp-for-connected-devices/</guid>
        <pubDate>Thu, 24 Sep 2026 00:00:00 GMT</pubDate>
        <description>A practical look at using MCP as a boundary between AI applications and MQTT-based systems.</description>
        <author>Duong (Young) Dang</author>
        <content:encoded><![CDATA[MQTT is a natural fit for connected devices: it is lightweight, event-driven, and already familiar in many IoT environments. AI applications, however, need more than a broker connection. They need a clear description of what they can inspect or change—and limits that are understandable to the system and its operator.

I developed an MQTT MCP integration to explore that boundary. The goal is not to give a model unrestricted access to every topic. It is to describe a deliberate set of capabilities through tools that an AI client can discover and use.

## Put a capability boundary in front

An MCP server can expose a small, well-defined surface: inspect a permitted value, read selected device state, or request an allowed action. This gives the AI client a consistent interface while the server owns the details of topic mapping, payload validation, and access rules.

The boundary matters. MQTT topics can represent sensitive or safety-relevant operations. A useful integration should keep permissions narrow, validate inputs, make writes explicit, and avoid treating a generated response as authorization.

## Design for uncertainty

Models can misunderstand intent or produce incomplete arguments. Tools should return structured outcomes, including clear failures and freshness information where relevant. For actions that affect equipment, a confirmation step and an auditable record may be more valuable than a fully autonomous flow.

The pattern is broader than MQTT: an AI system should use the same interfaces and operational safeguards as other software, with additional attention to ambiguity and human oversight.

## Keep the first use case small

Start with read-only visibility or a simulation. Confirm that the model selects the right tool, handles missing data, and explains results accurately before considering any action-oriented capability. That sequence lets you learn about the interaction without turning an experiment into an operational dependency.

Connecting AI to devices is exciting, but the integration itself is only one part of the work. The more important design question is: what should the AI be allowed to do, and how will a person know what happened?]]></content:encoded>
      </item>
      <item>
        <title>Portable AI Skills: Designing Workflows Across Different Tools</title>
        <link>https://example.com/blog/portable-ai-skills-workflows/</link>
        <guid isPermaLink="true">https://example.com/blog/portable-ai-skills-workflows/</guid>
        <pubDate>Fri, 18 Sep 2026 00:00:00 GMT</pubDate>
        <description>How to separate reusable workflow logic from the conventions of individual AI assistants and coding environments.</description>
        <author>Duong (Young) Dang</author>
        <content:encoded><![CDATA[AI tools keep multiplying. Claude, Cursor, OpenClaw, Hermes, and OpenCode each have their own strengths and interaction patterns, but many of the tasks we want them to help with are not unique to one application.

That raises an interesting question: can a useful AI workflow travel between tools without pretending that every tool works the same way?

## Separate the job from the wrapper

A reusable skill should begin with the task itself: its purpose, the inputs it needs, the steps it follows, the output it produces, and the conditions under which it should stop or ask for help. Those parts are the workflow’s core.

For example, a workflow definition can make the handoff and approval points explicit:

```yaml
workflow:
  input: validate
  context: gather
  proposal: show-user
  side_effects: require-approval
  report: summarize
```

Tool-specific instructions can then act as adapters. One assistant may load a skill from a directory, another may expect a command or a rules file, and a third may rely on a tool call. Keeping the core description and scripts independent makes it easier to translate the workflow without rewriting its intent.

## Make the workflow inspectable

An automation is easier to trust when its steps are explicit. A simple sequence might be:

1. Collect and validate the input.
2. Gather relevant context.
3. Propose the next action.
4. Request approval for consequential changes.
5. Execute and report what happened.

Scripts are useful for deterministic work such as formatting, validation, or moving data between systems. The model can help interpret ambiguous input, while ordinary code handles repeatable operations. Keeping those roles clear reduces surprises.

## Portability is not sameness

The goal is not a universal prompt that magically fits every product. It is a well-defined workflow with thin, honest adapters for the tools that support it. Each integration should document what it can do, what it cannot do, and where a human needs to stay involved.

I’m exploring this space by building reusable skills, scripts, and full workflow automations. A good measure of progress is not how many tools are supported—it is whether the workflow remains understandable and dependable when it moves between them.]]></content:encoded>
      </item>
      <item>
        <title>What a Real-Estate Research Agent Should—and Shouldn’t—Decide</title>
        <link>https://example.com/blog/real-estate-research-agents/</link>
        <guid isPermaLink="true">https://example.com/blog/real-estate-research-agents/</guid>
        <pubDate>Sat, 12 Sep 2026 00:00:00 GMT</pubDate>
        <description>A decision-support approach to property research, deal comparison, and matching opportunities to a person’s criteria.</description>
        <author>Duong (Young) Dang</author>
        <content:encoded><![CDATA[A real-estate research agent can help someone move from a pile of listings to a more focused set of questions. It can organize details, compare properties against stated criteria, and flag information that deserves a closer look. That does not make it a substitute for due diligence or professional advice.

I’m studying and building agents in this area, especially around matching opportunities to user-defined criteria. The most useful design starts with making those criteria explicit.

## Turn preferences into a transparent rubric

“Good deal” means different things to different people. One person may prioritize commute and monthly costs; another may care about renovation risk, rental demand, or long-term flexibility. An agent should capture those priorities, ask about missing constraints, and show how a match was scored.

Instead of returning a mysterious ranking, it can present a comparison: which criteria appear to fit, what information is missing, and what trade-offs are visible. That gives the user something to inspect rather than a verdict to accept.

## Keep facts and estimates distinct

Listings can be incomplete or out of date. A system should distinguish facts taken from a source from estimates or assumptions it derived. It should link back to the source where possible, identify missing data, and avoid presenting an estimate as verified truth.

## Make the person the decision-maker

An agent can organize research and prepare next steps. It should not imply certainty about legal, financial, or property conditions it cannot verify. Good decision support helps people ask better questions and compare options consistently; the final judgment stays with the person.

For me, the interesting challenge is less about making an agent sound persuasive and more about making its reasoning inspectable, its uncertainty visible, and its recommendations relevant to the user’s actual priorities.]]></content:encoded>
      </item>
      <item>
        <title>Small Agents for Everyday Work: Travel, Invoices, and the Human Handoff</title>
        <link>https://example.com/blog/agents-for-everyday-workflows/</link>
        <guid isPermaLink="true">https://example.com/blog/agents-for-everyday-workflows/</guid>
        <pubDate>Sat, 05 Sep 2026 00:00:00 GMT</pubDate>
        <description>Why focused agents often work better than one assistant that tries to automate everything.</description>
        <author>Duong (Young) Dang</author>
        <content:encoded><![CDATA[Some useful agent ideas are deliberately ordinary: search for flights that fit a set of preferences, gather invoices from a defined source, or organize the next step in a recurring task. I’m exploring agents for these kinds of personal workflows because they make the design questions concrete.

## Give each agent a narrow job

A flight-search agent might collect dates and constraints, compare options, and present a shortlist. An invoice workflow might gather documents, extract a few fields, flag mismatches, and prepare a review queue. Those jobs have clear boundaries and useful stopping points.

That is usually a better starting point than asking one agent to manage an entire travel plan or financial process autonomously. A narrow scope is easier to test, explain, and recover when something goes wrong.

## Automate preparation before commitment

Searching, sorting, extracting, and drafting are often good candidates for assistance. Booking a ticket, paying an invoice, or sending a consequential message should have a deliberate confirmation step unless the person has explicitly configured otherwise.

The handoff is part of the workflow, not a failure of autonomy. The system can show the information it gathered, explain decisions, and ask for approval at the right moment.

## Design for exceptions

Real workflows contain missing details, duplicates, changed prices, and documents that do not match expectations. A useful agent should surface these cases clearly and leave them for review instead of forcing every situation through the happy path.

I’m interested in building small personal agents that remove repetitive effort without hiding the important choices. The best automation may not be the one that acts the most—it may be the one that helps a person act with less friction and better information.]]></content:encoded>
      </item>
      <item>
        <title>Connecting Factory Software Starts with Understanding the Work</title>
        <link>https://example.com/blog/connecting-factory-software/</link>
        <guid isPermaLink="true">https://example.com/blog/connecting-factory-software/</guid>
        <pubDate>Fri, 28 Aug 2026 00:00:00 GMT</pubDate>
        <description>A business-analysis view of integration projects: map the process, find the handoffs, and make reliability part of the design.</description>
        <author>Duong (Young) Dang</author>
        <content:encoded><![CDATA[“Integrate these two systems” sounds like a technical request. In a factory, it is also a question about people, timing, exceptions, and responsibility. What information needs to move? Who relies on it? What happens when it arrives late—or not at all?

Business analysis is a useful starting point for integration work because it helps make those questions visible before implementation details take over.

## Follow the information through the process

Begin with the operational event: a new order, a completed production step, a label request, or a device update. Trace where the information originates, how it is transformed, and who or what depends on it next. The map should include the ordinary path and the exception paths.

This often reveals that two systems use similar words to mean different things, or that a manual handoff is doing important validation which no one has documented.

## Reliability is a workflow concern

Retries, duplicate messages, delayed updates, and partial failures are not edge cases when a process depends on continuous operations. The integration should define how it detects these conditions, how a person can see what is happening, and how the work can be recovered.

That is as much about operational clarity as it is about protocols. A technically successful connection is not useful if people cannot understand its status or safely resolve a problem.

## Connect systems around outcomes

The goal is not to connect every system to every other system. It is to give the right people and processes the right information at the right time, with enough traceability to know where it came from.

The better the shared understanding of the work, the easier it is to choose a sensible integration pattern—and to know whether the result actually improved the process.]]></content:encoded>
      </item>
      </channel>
    </rss>