1. Start With the Unsolved Problem, Not the New Technology

The original 觀音 application already solved a specific problem well: users could draw or enter a fortune-stick number and retrieve the corresponding interpretation.

Generative AI did not make that mechanism obsolete.

A deterministic lookup remains faster, more predictable and more appropriate for deterministic content.

The opportunity appeared somewhere else.

The traditional product could provide an interpretation, but it could not understand why the user asked the question, what was happening in their life, what they were feeling, or what decision they were trying to make.

That was the unsolved problem.

The lesson is simple:

Do not begin an AI project by asking where AI can be added.

Begin by identifying what the existing product still cannot do.

AI should earn its place by solving that problem better than the existing system.

2. Do Not Replace Deterministic Systems With Probabilistic Ones Without a Reason

Generative AI is powerful, but that does not make it the best tool for every part of a product.

The fortune-stick database already knows the canonical content associated with each stick.

There is little value in asking an LLM to regenerate information that can be retrieved exactly.

This principle applies far beyond fortune-telling applications.

If a value can be calculated exactly, calculate it.

If a record can be retrieved reliably, retrieve it.

If a rule can be enforced deterministically, enforce it.

Use generative AI where interpretation, language, ambiguity, contextual reasoning or synthesis actually matter.

AI architecture should complement reliable software, not replace it indiscriminately.

3. Give AI a Clearly Defined Responsibility

One of the most important decisions in 觀音AI was defining what AI should and should not do.

The division became:

觀音靈簽 provides intuition, symbolism and insight.

AI provides reasoning, objectivity, emotional steadiness and practical next steps.

Without that separation, the easiest implementation would have turned the LLM into an electronic fortune teller.

That would have blurred symbolic interpretation and factual reasoning.

A clear responsibility boundary made later decisions easier.

The fortune could introduce a perspective without becoming evidence.

The AI could reason about the user's situation without pretending to know the future.

The user could remain responsible for the final decision.

Before choosing a model, framework or agent architecture, define the job AI is actually being asked to perform.

4. Decompose Responsibilities Before Creating Agents

Multi-agent systems can easily become architecture for architecture's sake.

The useful question is not:

How many agents should this system have?

The useful question is:

What different responsibilities exist inside this problem?

A user's question may require symbolic interpretation, rational analysis, emotional awareness and practical action.

Those responsibilities have different objectives.

Some can challenge others.

That makes separation useful.

An agent should therefore represent a meaningful responsibility, not merely another AI personality.

Agents should emerge from decomposition of the problem.

Do not invent responsibilities to justify more agents.

5. Collaboration Matters More Than Agent Count

Several agents producing several independent answers do not automatically create a better system.

The value comes when their perspectives affect one another.

A symbolic interpretation may suggest patience.

Rational analysis can prevent that idea from becoming an unsupported prediction.

Emotional analysis can identify whether urgency is being driven by anxiety.

Practical reasoning can determine whether acting immediately actually improves the situation.

The final response becomes stronger because the perspectives constrain and complement one another.

This leads to a useful principle:

A multi-agent system should behave like a collaboration, not a collection of prompts.

If the final architecture simply concatenates independent outputs, the additional complexity may not be justified.

6. Keep Internal Complexity Out of the User Interface

觀音AI may contain multiple specialized reasoning roles internally.

The user should not have to manage them.

Someone facing a relationship problem should not need to decide whether to consult the rational agent, emotional agent or action agent.

That is an implementation concern.

The user talks to one 觀音AI .

This principle applies broadly to sophisticated AI products.

Internal specialization can be valuable.

Exposing that specialization is valuable only when it helps the user accomplish something.

Otherwise:

complexity should remain inside the system so that the experience can remain simple.

7. A System Instruction Is Part of the Product

In conventional software, developers tend to think of product behavior as something implemented primarily through code.

LLM systems add another important artifact: instructions.

Instructions define roles, boundaries, priorities, collaboration rules and expected behavior.

Changing those instructions can change the product as materially as changing source code.

Prompt design is therefore not merely a matter of finding clever wording.

It is part of system design.

Important instructions should be treated with the same discipline as other product artifacts:

• explicit ownership;
• versioning;
• testing;
• review;
• documented intent.

If instructions control product behavior, instructions are part of the architecture.

8. Privacy Can Improve Product Quality

Privacy is usually discussed as protection against something going wrong.

觀音AI exposed another dimension.

The usefulness of conversational AI depends on the quality of the context users provide.

If someone is discussing a relationship, career failure, family conflict, fear or regret, they may censor themselves if they believe the conversation is being sent somewhere they do not control.

That means privacy can affect the input itself.

Incomplete honesty produces incomplete context.

Incomplete context can produce weaker reasoning.

Therefore:

privacy is not only about protecting data after the conversation. It can change the quality of the conversation.

For products involving highly personal context, privacy can become a core product capability rather than merely a compliance requirement.

9. The Strongest Data-Protection Strategy Can Be Architectural

Encryption, access controls, retention policies and privacy policies are all useful.

But sometimes the strongest design question is more fundamental:

Does this data need to leave the device at all?

For 觀音AI , on-device inference provides a strong answer.

If the model can process the conversation locally, private conversational content does not need to be transmitted to a remote LLM simply to obtain a response.

This does not mean cloud AI is inherently insecure.

It means architecture can sometimes eliminate a category of data exposure rather than merely managing it.

Good privacy architecture reduces unnecessary data movement.

10. On-Device AI Turns Model Selection Into Systems Engineering

Choosing a cloud model can feel like selecting a service.

Choosing an on-device model is much more physical.

The model occupies storage.

It consumes memory.

It generates runtime state and caches.

It competes with the operating system and application for resources.

It affects latency, thermal behavior and battery use.

It determines which devices can realistically run the product.

The best benchmark result therefore does not necessarily identify the best model.

The relevant question is:

Which model provides enough intelligence within the physical constraints of the product?

That changes model selection from a pure AI-quality decision into systems engineering.

11. Logical Architecture and Physical Execution Are Different

A multi-agent architecture may contain several logically independent roles.

That does not mean all of them should execute simultaneously.

On mobile hardware, parallel inference can increase peak memory pressure, compute contention, thermal load and energy consumption.

Several agents can therefore exist logically while sharing one model and executing conservatively.

This distinction is useful beyond mobile AI:

architecture describes responsibilities; execution describes how those responsibilities are scheduled on real resources.

Do not confuse conceptual parallelism with a requirement for physical concurrency.

12. More Agents Are Not Free

Every additional reasoning step has a cost.

In cloud systems, that cost may appear as API usage and latency.

On-device, it can also appear as battery consumption, heat, memory pressure and slower responses.

This means agent count should not become a vanity metric.

A new agent should exist only when separating that responsibility creates enough improvement to justify the runtime and architectural cost.

The same principle applies to additional reasoning passes, tools and context.

Complexity should have measurable value.

13. Stored Memory and Active Context Are Different Things

Conversation continuity is valuable.

Unlimited context is not practical.

A user may accumulate a long history over weeks or months, but the model does not need every previous message to answer every new question.

The architecture should distinguish between:

stored conversation history

and

the context required for the current reasoning task.

Relevant context might include:

• an unresolved issue;
• an action previously suggested;
• a change the user was waiting for;
• an important emotional concern;
• the relevant fortune-stick context.

This separation improves efficiency while preserving continuity.

The general lesson is:

remember broadly, reason selectively.

14. Conversation History Should Create Future Value

Saving old conversations is not enough.

History becomes valuable when the product can use it to improve what happens next.

A generic starter prompt might say:

Ask me about your career.

A contextual follow-up can say:

Were you able to speak with your manager?

The second prompt understands that a process is already underway.

That transforms history from an archive into product intelligence.

The principle is applicable to many conversational systems:

memory should help continue the user's work, not merely preserve a transcript of it.

15. AI Can Shift the Engineering Bottleneck From Code to Intent

AI coding tools can produce implementation much faster than traditional manual development.

That does not eliminate engineering work.

It changes where the difficult work happens.

The critical questions increasingly become:

• What exactly should be built?
• What should remain unchanged?
• Which artifact represents the approved decision?
• What constraints must the implementation respect?
• What is experimental?
• What is actually released?
• What does success look like?

When implementation becomes faster, vague requirements become more expensive because AI can generate large amounts of incorrect work very quickly.

The cheaper code becomes, the more valuable precise intent becomes.

16. AI Generation Makes Sources of Truth More Important

Generative tools make exploration extremely cheap.

A team can generate several designs, architectures, feature concepts and implementations in a short period of time.

That abundance introduces a new problem.

A generated idea can easily be mistaken for a decision.

A proposed feature can be mistaken for something implemented.

A screenshot experiment can be mistaken for an approved design.

A plausible architecture document can be mistaken for the actual architecture.

AI therefore increases the importance of explicit project artifacts and clear sources of truth.

Generation creates possibilities. Engineering still has to decide what is real.

17. Architecture and Product Requirements Evolve Together

The development of 觀音AI did not follow a clean sequence of requirements first, architecture second and implementation third.

Each decision exposed another requirement.

Static interpretation led to conversation.

Conversation created context.

Context created continuity.

Continuity created memory.

Memory increased the importance of privacy.

Privacy pushed inference onto the device.

On-device inference created hardware constraints.

Richer reasoning encouraged multi-agent decomposition.

Multi-agent reasoning introduced orchestration and performance costs.

Those technical constraints then influenced the product.

This feedback loop is normal.

Architecture does not merely implement product decisions. Building the architecture can reveal what the product needs to become.

18. Constraints Can Improve the Product

Constraints are often described as obstacles.

They can also create discipline.

On-device inference limits model size.

Mobile hardware limits how much reasoning can happen simultaneously.

Privacy limits what data should leave the device.

The distinction between fortune and AI limits what the model should claim.

These restrictions reduce the solution space.

That can be useful.

Without constraints, generative AI makes it easy to add capabilities indefinitely.

With constraints, each capability has to justify itself.

A well-chosen constraint can produce a clearer product.

19. Technical Leadership Is Increasingly About Coherence

AI can generate code.

It can propose architectures.

It can create designs.

It can draft requirements.

It can suggest product features.

The difficult part is increasingly keeping all of those outputs aligned with the same product intent.

Does the implementation still reflect the privacy promise?

Does the architecture still respect device constraints?

Does an agent still have a clear responsibility?

Did a generated feature quietly change the product direction?

Does the interface communicate what the architecture actually guarantees?

Technical leadership becomes the work of maintaining coherence across product, architecture, implementation and user experience.

Speed without coherence produces faster confusion.

20. Build the Smallest AI System That Solves the Real Problem

觀音AI could have become a much larger AI system.

More agents could have been added.

More conversations could have been sent to larger cloud models.

More user information could have been collected.

More generated features could have been introduced.

None of those things automatically creates more value.

The better question is always:

What is the smallest system that solves the user's real problem well?

For 觀音AI , the answer begins with a traditional fortune stick that provides a perspective.

AI then helps the user understand the situation from several complementary angles.

Specialized reasoning responsibilities collaborate.

The response is synthesized into one conversation.

The user retains the final decision.

And private context can remain on the device.

That is enough complexity to create something the original application could not do.

Anything beyond that has to earn its place.

Closing Principle

The most important lesson from 觀音AI is not about fortune telling, language models, agents or mobile inference.

It is about the order in which technical decisions should be made.

Problem
   ↓
Responsibilities
   ↓
Product boundaries
   ↓
Privacy requirements
   ↓
Architecture
   ↓
Model and runtime
   ↓
Implementation

Starting from technology reverses that sequence.

It encourages teams to choose a model, an agent framework or an AI platform and then search for a reason to use it.

The better approach is to begin with the job that remains unsolved.

Define what AI should contribute.

Define what it should not do.

Separate responsibilities where separation improves reasoning.

Choose an architecture that protects the properties the product depends on.

Then select technology that can implement those decisions within real constraints.

The architecture should follow the problem.

The AI should follow the responsibility.

And the technology should serve the product—not become the product.