Help people clarify relationship expectations, before assigning labels.

At the start of my involvement, I mapped the overall Agent architecture from the product goal, connecting knowledge, character principles, behaviour, understanding, dialogue strategy, question selection, response generation and evaluation.

My current focus is the Relationship Knowledge Architecture, RKA. I am also primarily responsible for subsequent Character, Behavior, Reasoning/Formulation and Conversation Strategy design.

Scope and stage

• Design artifacts: initial overall architecture, relationship knowledge, answer-handling rules, profile specifications and exploration methods.
• Ongoing work: detailed character, behaviour, understanding and strategy requirements; design examples show how these parts connect.
• Team implementation: conversation, profiles and memory have usage records; integration of individual specifications needs to be checked against implementation.
• Future matching: formal recommendations are not yet open. This case explains information organisation and use requirements.

The case focuses on my Agent-design work; a stage-specific demonstration does not establish implementation of the complete system.

The same label can mean different things: listening carefully, staying engaged during disagreements, or giving notice when busy.

The team explores a product for young adults in Hong Kong who find relationship needs difficult to express and compatibility difficult to assess. Dialogue helps make broad expectations concrete, supporting later relationship understanding and discovery.

Basic information can be entered directly. Context-dependent material benefits from gradual conversation. AI dialogue also introduces requirements: limit question burden, avoid unsupported attribution, and preserve correction and stopping.

1. 01Establish a starting point
2. 02Express and clarify
3. 03Inspect and revise the profile
4. 04Decide information uses
5. 05Discover and update over time

Users need not arrive with every expectation resolved. During dialogue the Agent checks whether clarification is needed. Afterwards users need to understand the result, correct inaccuracies and know what may be public or used in later matching.

The aim is not to fill the profile quickly. Each exchange should leave sufficiently specific, revisable information with a clear purpose.

The architecture starts with the product goal and connects eight areas: knowledge foundations, character principles, outward behaviour, situational understanding, dialogue strategy, question selection, response generation and evaluation.

Knowledge supports interpretation; character principles constrain judgment; formulation identifies the current need; strategy selects the next action; question selection and generation execute it. A new user answer changes the current understanding.

The intended runtime is a decision loop, rather than sequential retrieval from a question bank. Evaluation needs to trace problems back to knowledge, judgment, action or expression.

I organise relationship knowledge into surface-level information, deeper exploration, compatibility and relationship goals. Each Topic specifies how to locate information, interpret an answer and choose an action.

Topic example: contact and online interaction

This Topic covers contact habits, reply rhythms, initiative, sharing and expectations of a partner's related behaviour. Relationship pace, emotional support, account privacy and conflict repair belong to other Topics, whose existing information can be reused.

These boundaries affect knowledge use. A slow reply calls for context, not an immediate conclusion of emotional distance. Access to an account should not continue to be handled as a contact-frequency question.

Issue: contact frequency, reply rhythm and acceptable differences

I distinguish four things: actual contact habits, typical reply behaviour, desired contact between partners, and differences a user can accept.

Reference questions include how often someone wants contact when apart and how this changes when busy, versus when they usually reply to messages. One asks about expectations; the other asks about personal habits. The answers are not interchangeable.

How an answer changes the next action

“When I'm busy, I may reply to everything in the evening.”

This describes a personal habit under a busy condition. The specification records both without inferring detachment, low commitment or an identical demand of a partner. More questions are needed only if the missing detail matters to the current understanding.

“I don't need an immediate reply, but if there's no message all day, I'd like an explanation.”

This supplies an acceptable delay and a condition for notice. The specification preserves that boundary without inventing a two-hour or half-day limit. Once the current purpose is clear, the Agent can stop.

Evidence resolves a gap; it is not a demand to prove every answer

An explicit expectation can be recorded within its stated scope. A concrete situation is needed when wording such as “reply promptly” remains ambiguous and the difference matters. No experience, no definite requirement and unwillingness to discuss remain distinct states.

Reference questions are therefore not a mandatory checklist. Each turn first checks whether the information already available is sufficient, rather than asking enough questions to cover the knowledge base.

From Topic requirements to relationship information

The record retains the original expression, specific content, Topic, person concerned, applicable situations such as being busy, condition strength and confirmation state. It expresses how the user hopes to relate, not an agreement already reached by both people.

These distinctions affect downstream use. Missing information about a candidate's reply habits does not mean the condition is met. A preference cannot become a hard filter unless the user has established it as a requirement.

Knowledge locates the answer; information state identifies the gap; dialogue strategy decides whether to ask; recording rules constrain downstream use. The Topic does not turn conversation into a fixed questionnaire.

The Agent can help clarify and organise expression. It cannot turn one answer into a personality conclusion or automatically treat the user's own habits as demands of a partner.

The knowledge-use, profile and general-questioning rules separate direct expression, tentative interpretation and unknown information. Users can correct, decline or end; deeper exploration depends on the task and willingness.

Further character and behaviour design will specify emotional responses, disagreement, admitting uncertainty and stopping. Tone must be consistent with these judgments, rather than a friendly persona paragraph alone.

Dialogue decision example

User: I want someone who communicates well.

Agent: What would they do that makes communication feel good to you?

User: If we disagree, I'd like them to talk it through instead of disappearing.

The first answer gives an abstract expectation. The gap is what “communicates well” means, so the next move is clarification, rather than an attachment-style inference or an inquiry into trauma.

The second answer supplies a situation and expectation: staying responsive during disagreement and discussing it together. The Agent can summarise and check instead of selecting another question.

Agent: What matters is that they stay engaged when you disagree and work through it with you. Have I understood that correctly?

This connects interpretation, gap detection, clarification versus summarisation, depth control, and a reply that executes only the chosen action. A denial should lead to correction of the understanding.

Labels such as “values communication” or “prefers little contact” lose context. The relationship model needs specific conditions and a distinction between behaviour, future expectations and mutual arrangements.

One update example in the profile document starts with a low-contact interpretation; the user later clarifies that replying is difficult only during work. The applicable condition needs revision. Low contact should not remain a general preference.

I distinguish filling gaps, explaining concepts, adding conditions, adding behavioural evidence, correcting interpretations and updating states. New information need not overwrite the old: difficulty replying at work and wanting daily contact can coexist.

Expectations also differ from demonstrated behaviour. One initial profile records a desire for daily contact without instant replies at work, alongside no relationship experience. This supports further understanding, not a conclusion of proven communication skill or predictable future behaviour.

Records need sources and confirmation states. Direct statements retain their scope; Agent synthesis remains tentative. Retelling one experience does not create multiple independent pieces of evidence.

Profile accuracy and permission to disclose are separate decisions. Matching also depends on confirmation, permitted uses and sufficient information about the other person.

Similarity, attraction and compatibility are different. Shared interests can start a conversation, but responses, daily arrangements and handling differences require more specific information.

Firm conditions differ from general preferences. Unconfirmed inferences must not become filters, and absent information does not establish that a requirement is met. Formal recommendations are not yet open; these specifications constrain future implementation.

The architecture, RKA, profile and conversation methods give the team a shared reference. The next step is to turn situations into inspectable expectations: user input, known information, intended action, recording requirements and behaviours to avoid.

Evaluation will examine information reuse, unsupported inference, unnecessary questions, respect for stopping and profile correction. Repeated questions may mean information was not saved, not supplied or not used. These causes need different changes to knowledge, state, strategy or wording.

My approach to Agents starts with the user's task, defines what the system needs to know, judge, express and remember, and connects those capabilities to the product journey.