AI agents are becoming a new interface not only for finding people, but also for maintaining the profile that other agents search. Instead of manually editing a self-introduction and guessing keywords, a user can simply work with their agent. As the user makes requests, rejects options, and reveals preferences, the agent turns those signals into a structured, searchable profile.
This post walks through the backend design behind the Impression Management process in Opportunity Skill, which makes a user discoverable to other agents and supports products like Claude Code and OpenClaw.
A profile for agents, not just for humans
Traditional profiles optimize for human readability and persuasion. An agent-searchable profile needs to be structured for continuous updates, specific enough for semantic matching, compact enough to avoid contradictions, and fresh enough to reflect current needs. That is what impressions are: profile units designed for downstream semantic use, not just self-description.
The skill instructs the agent to analyze tacit preferences, including negative signals like "remove X" or "do not use Y," and summarize them as impressions with tags. A preference for strict type definitions, for example, may be inferred as valuing long-term maintainability and written into a public impression.
Two perspectives, two profiles
The skill treats the user as two distinct search identities: buyer and professional. The same founder may want to hire engineers as a buyer while also being discovered as a strategist as a professional. These contexts should not share a search surface.
Each user has two external candidate IDs, and every impression carries a perspective label. This prevents cross-context pollution and keeps matches precise.
The data model
The write path touches three tables. Impressions store semantic statements about the user. Tags store reusable concept labels with their own vector embeddings. A join table links them. Both impressions and tags carry a public flag and are embedded immediately at write time, making the profile searchable without waiting for offline indexing.
Reading the public snapshot
The read function returns basic user information plus current public impressions with their tags. It filters only publicly visible impressions because this endpoint exposes the discoverable layer, not internal notes. The agent uses this snapshot to decide whether new observations are already covered, conflict with existing content, or require a refresh.
From observation to structured unit
The backend does not infer impressions itself; the agent does the reasoning. The agent uncovers tacit preferences from approvals, rejections, and requirements, then submits structured impression units with one to five tags each.
The server validates the schema, normalizes content by collapsing line breaks and truncating to 1024 characters, and ensures every write is explicitly public. This enforces a contract: the agent interprets behavior, and the server enforces consistency and limits.
There is no fixed taxonomy. When the agent submits new tags, the server reads existing ones by name, creates embeddings for any missing labels, inserts them, and returns the full set of IDs. The tag vocabulary grows dynamically, which is essential for real-world preferences that do not fit into a pre-approved list. The schema also reserves a dual embedding column for model migration without downtime.
Real-time refresh as create-plus-cleanup
The system does not edit impressions in place. Instead, it appends better units and removes competing old ones.
Before inserting new impressions, the server deletes existing impressions in the same perspective whose embeddings are within a 0.1 cosine distance of the new ones. This catches semantic redundancy even when wording differs. For impressions that are outdated but not caught by automatic deduplication, the agent can explicitly delete them using a prefix-match interface.
There is no mutable update API in the AI-facing flow. Curating a compact semantic set is more robust than repeatedly mutating one long text blob. The design favors replacement over patching.
Tags are a core part of the search architecture. The two-stage pipeline described in the previous article uses tags as a lightweight semantic recall layer: it matches query embeddings against tag vectors to find candidates, then reranks using impression content. Therefore, every impression's tags determine how other agents will discover the user. They are not merely metadata.
Not the same as agent memory
Impressions and agent memory are related but serve different audiences. Memory is private, contextual, and for the current agent's continuity. Impressions are public, structured, embedded, and intended for downstream discovery by other agents. Memory can be rough; impressions must be stable enough to represent the user externally.
The full mental model
The flow works as follows. The agent observes a new preference and reads the latest public profile. It classifies the observation as buyer or professional perspective, formulates structured impressions with tags, and submits them. The server validates and normalizes the payload, resolves tags by reading or creating them on demand, embeds the impression texts, and deletes semantically overlapping old impressions within the same perspective. It then inserts the new public impressions and links them to tags. Afterward, the agent notifies the user and can optionally enrich basic information. Any remaining outdated impressions are explicitly removed. The profile is now refreshed and immediately searchable.
Engineering takeaways
- Agent-searchable profiles should be semantic units, not one long blob. Structured impressions are easier to maintain, search, and explain.
- Separate public profile maintenance from private agent memory. Not every inferred preference should become externally discoverable.
- Real-time refresh works better as append-and-prune than in-place editing. Creating new impressions and pruning semantic duplicates is more robust than mutating a large text field.
- Tags are a lightweight interface between writing and retrieval. Without them, the downstream search pipeline loses its recall layer.
- Perspective separation matters. Buyer and professional identities are different search objects and should remain distinct.
- Agent-facing APIs still need strict server-side contracts. Validation, normalization, and clear failure semantics remain essential even when the caller is an agent.
Closing
Opportunity Skill is built on the belief that in the agent era, your profile should be continuously maintained in a form that other agents can search, interpret, and act upon. The Impression Management pipeline turns everyday interaction signals into public semantic units, perspective-specific discoverability, immediate vectorized refresh, and automatic cleanup. Together with Search and Contact and Lead Engagement, it creates a self-reinforcing loop: every preference you reveal makes you more precisely discoverable.
If you want to try the skill, ask your agent to install it from: https://github.com/QuestMeet/opportunityskill/releases/download/latest/opportunity-skill.zip
