AI agents are becoming the new work interface. When a founder no longer opens LinkedIn to search for talent themselves, but instead tells their AI agent: "Find me a remote full-stack developer suited to an early-stage SaaS team" — your career profile faces a fundamentally new question. Can it be effectively retrieved and understood by an AI agent?
Traditional profiles are designed for human eyeballs. LinkedIn summaries, resumes, personal homepages — they optimize for readability and persuasiveness. But when an AI agent does matching, it's not asking "is this person impressive?" It's asking "how close is the semantic distance between this person and this need?" Display-type profiles and matching-type profiles are diverging. The former is optimized for human reading; the latter for machine understanding and semantic matching.
If a matching-type profile genuinely matters, how should it be created and maintained? Periodic manual updates are clearly unrealistic. No one can track every preference shift, every rejection signal, every newly surfaced need expressed through feedback — and then write them all into high-semantic-density structured descriptions. This article walks through Opportunity Skill's Impression Management workflow: how an AI-searchable profile gets maintained through the skill's recurring processes. There will be technical detail, but no code — we'll stick to design rationale and engineering decisions.
A matching-type profile is not a "write once and you're done" thing
Traditional profiles are static. You update LinkedIn when you change jobs. Maybe you add a line after a major project. Otherwise, it mostly sits untouched.
But a career portrait in the AI agent era is dynamic. Your preferences change. You used to take short-term projects; now you only want long-term collaborations. You used to accept high-frequency sync meetings; now you prefer async documentation-first workflows. You used to take work across any industry; now you only want AI tools and developer ecosystems. Your collaboration style changes too. You start valuing type safety more. You care more about maintainability. You become more averse to projects where requirements are chaotic but delivery pressure is high.
These changes rarely make it into LinkedIn in a timely way. But they do show up — in your daily conversations with your AI agent, in project discussions, in task selections, in feedback. You say "I don't want that style." You veto a proposal. You insist on strict type definitions. Between two versions, you choose the one that prioritizes long-term maintainability. Every one of these moments emits a signal about you.
Maintaining a matching-type profile, at its core, means converting such signals into structured semantic units that other AI agents can search against. This is not a task humans can sustain. It has to be done by an AI agent. That is the starting point of Opportunity Skill's Impression Management workflow.
The whole Skill is a self-reinforcing loop
Before diving into Impression Management, it's worth understanding Opportunity Skill's overall architecture. It contains six modules: Authentication, User Representation, Human Card Management (which includes Impression Management and Profile Management), Human Discovery, Human Outreach, and Lead Engagement.
Authentication is the starting point — it provides the access token every other module depends on. User Representation is a read-only module that retrieves the user's complete public-facing representation to support self-referential tasks. Human Discovery and Human Outreach form the active search channel: your AI agent searches for matching buyers or professionals, generates tailored collaboration proposals, and sends them. Lead Engagement is the passive channel: your AI agent reads recent spaces and chat messages, identifies high-value leads and drafts replies, while filtering out irrelevant marketing noise.
The critical design insight is this: as Human Discovery, Human Outreach, and Lead Engagement run, they discover new user attributes and preferences. The leaning you reveal when confirming or revising a collaboration proposal. The trade-off criteria you demonstrate when deciding whether to reply to a lead. These new discoveries are fed back into the Impression Management workflow to update your public profile. And a more precise profile improves the quality of the next round of search and matching.
This is a self-reinforcing loop. Every preference you reveal makes you more precisely discoverable.
Two profiles, not one
Opportunity Skill makes an architectural choice that's easy to overlook but has far-reaching implications. It treats each user as two distinct search identities: buyer and professional.
The same person might search for engineers as a buyer while simultaneously being discoverable as a strategy consultant under their professional identity. These two scenarios should not share the same search surface. If "I'm hiring" signals and "I'm available for projects" signals are blended together, search results get fuzzy and match quality degrades.
The system maintains two outward-facing candidate IDs for each user. Every impression carries a perspective tag. Impressions written to the buyer perspective never pollute professional-side search results, and vice versa. This distinction is enforced at the data model level — not by having the AI agent manually filter at search time.
An impression is a semantic unit, not a score.
In Opportunity Skill, the basic unit of a profile is not a "work experience entry" or a "self-description paragraph." It's the impression. The term here does not mean a vague notion like "first impression" or "impression score." It means a structured, tagged, publicly visible statement that can be vectorized and semantically matched.
Take a concrete example. A freelance full-stack developer's LinkedIn summary might read: Senior full-stack developer. Proficient in React, Node.js, and cloud deployment. Extensive SaaS product experience. Strong communication skills. This is a perfectly competent human-readable summary.
But in Opportunity Skill, the AI agent might translate it into multiple impressions. Such as: Suited to early-stage SaaS or AI tool teams. Can decompose deliverable full-stack functionality from vague requirements. Typically starts by mapping business goals, user journeys, technical risks, and acceptance criteria before moving into implementation. Can align priorities with founders in the absence of a complete PRD, and break uncertainty into verifiable small releases. Tags: Early-stage SaaS, AI Tools, Full-stack Delivery, Product Thinking, Requirement Clarification.
Another: Values type safety, test coverage, and maintainability across both front-end and back-end implementation. Prefers TypeScript strict mode, clear data models, and evolvable module boundaries. Not suited to one-off deliveries that prioritize speed-to-market over refactoring headroom. Tags: TypeScript, Type Safety, Maintainability, Testing, Architecture.
Notice the information density of these two impressions. They don't just say "what I can do." They also say "in what environment," "in what way," and "what I'm not suited for." To an AI agent, this kind of information is far more useful than a generic label like "Senior Full-stack Developer." Because when an AI agent does matching, it's not asking "is this person impressive?" It's asking "how close is the semantic distance between this person and this need?"
The AI agent reasons. The server executes.
There's an important division of labor here. Reasoning work is done by the AI agent. The server does not independently infer impressions. The skill's instructions require the AI agent to observe the user's requests and feedback across multiple triggers — when impression management runs during conversations, when human discovery searches reveal new attributes, when feedback on outreach proposals surfaces requirements, when lead engagement processes messages, and when recurring scheduled tasks periodically refresh the representation — surfacing implicit preferences in each case. If the user says "I don't want that style," the AI agent analyzes what common traits the rejected options share. If the user consistently insists on strict type definitions, the AI agent may infer a deeper value for long-term maintainability. If the user chooses one option among several, the AI agent analyzes the differences between the chosen and discarded versions.
Once the AI agent completes its reasoning, it submits structured impression units to the server. Each unit contains an impression text and 1 to 5 tags. The server's responsibilities are: validation, normalization, storage, vectorization, and deduplication. It does not "understand the user." This division is healthy. AI agents excel at reading context and inferring implicit preferences. Servers excel at enforcing contracts and maintaining data consistency.
How the server enforces the contract
When the AI agent submits an impression, the first thing the server does is validate and normalize. Even if the AI-side Python wrapper has already validated against the schema, the server parser validates again. An AI-facing API should never assume a caller is well-behaved just because a reference client performed client-side validation.
Normalization involves two actions. Collapsing newlines — multiline text is flattened into a single line. Truncation to 512 characters. This directly enforces the constraint in the Skill specification: each impression is at most 512 characters. This limit isn't arbitrary. It exists to keep semantic units compact — preventing a single impression from ballooning into a long-form essay.
Next comes tag resolution. The system does not maintain a fixed tag taxonomy. When the AI agent submits new tags, the server reads existing tags by name. For tags that don't yet exist, it calls the embedding model to generate a vector and inserts them. It then returns the complete set of tag IDs. The tag vocabulary grows dynamically. This design is critical for real-world user preferences — many discriminating preference descriptions simply cannot be captured by a predefined tag list.
Real-time refresh. Create and prune, not edit in place.
Most profile systems operate on a mental model of "edit an existing record." You open a settings page, modify a block of text, save. But Opportunity Skill's AI write path works differently. Its refresh logic is closer to: observe something new, create a better impression, remove semantically redundant old ones.
Specifically, before inserting a new impression, the server first deletes any existing impressions under the same perspective whose embedding vector has a cosine distance of less than 0.1 from the new impression. This means that even if two impressions use completely different wording, as long as they are semantically highly overlapping, the old one gets automatically cleaned up.
Deduplication uses vector distance, not text comparison. Two impressions might say "prefers long-term iteration and continuous refactoring" and "suited to projects requiring long-term maintenance and architectural evolution." Different words. Semantically close. Embedding vectors can capture this similarity. Text comparison cannot.
For outdated impressions that are superseded by new observations but don't semantically overlap enough for auto-cleanup, the AI agent can use the explicit deletion interface. The deletion interface accepts content-prefix matching — the AI agent doesn't need to pass back the full stored text, just a prefix that identifies the target. This lowers the maintenance cost on the AI agent side.
There is no "modify an impression" API in the system. This is not an omission. It's intentional. Maintaining a compact semantic set through "append better units, prune competing old ones" is more robust than repeatedly editing a large block of text. The design favors replacement over patching.
Each impression carries 1 to 5 tags. These are not for aesthetics. They are not optional metadata. Tags are a core component of the search architecture.
Opportunity Skill's search pipeline uses a two-stage design. Stage 1 matches query vectors against tag vectors to find candidates. Stage 2 re-ranks using impression content. Tags form the lightweight semantic recall layer — they determine whether a user gets hit in the initial filter at all.
This means that when the AI agent writes an impression, it is not just describing what the user is like. It is simultaneously deciding how the user will be discovered in the future. Tag selection directly impacts discoverability. Good tags should be specific: TypeScript, Remote-first, B2B SaaS, Early-stage, Async Collaboration. Not generic fluff like "Professional," "Hard-working," "Passionate." Generic tags have almost no discriminative power in semantic space.
Tag embedding vectors and impression embedding vectors are stored in the same table, and the schema reserves dual embedding columns: odd_embedding and even_embedding. Any given row fills only one of the two columns. This design supports zero-downtime embedding model migration. When it's time to switch to a new embedding model, the system can gradually populate the other column, then flip the active column — no full-table rebuild required.
Impressions are not memory
There's an easy conceptual confusion here: impression vs. memory. Memory is typically private, context-bound, and maintains continuity between the current AI agent and its user. It can be rough, fragmented, and temporary.
Impressions are different. Impressions are public, structured, already embedded as vectors, and oriented toward downstream discovery by other AI agents. Memory can be rough. Impressions must be stable enough to represent their subject outwardly.
All impressions are public-facing by design. What your AI agent distills about you and writes as impressions becomes part of your discoverable professional identity.
The complete write-side mental model
Now we can trace the full Impression Management workflow end to end.
The AI agent, in the course of collaborating with the user, observes new attributes or preferences across multiple triggers: when impression management runs during conversations, when human discovery searches reveal new attributes, when feedback on outreach proposals surfaces requirements, when lead engagement processes messages, and when recurring scheduled tasks periodically refresh the representation. If the AI agent suspects that its currently cached user information may be stale, it first calls the read interface to fetch the latest public profile snapshot — including basic info and all current impressions with their tags.
The AI agent classifies the new observations as buyer-perspective or professional-perspective. It formulates structured impressions, each with 1 to 5 tags, and submits them.
The server receives the submission. Validates the schema. Normalizes each impression. Reads existing tags by name, generates embedding vectors for any tags that don't yet exist, and inserts them. Then embeds the impression text. Within a single transaction: first, deletes any same-perspective old impressions whose embedding distance from the new one is less than 0.1; then inserts the new public impression; finally, creates the association edges between the impression and its tags.
On completion, the AI agent receives a success message, notifies the user that their profile has been refreshed, and may optionally ask whether the user's basic info should be enriched based on the latest impressions. If the AI agent finds legacy stale impressions that weren't caught by auto-deduplication, it can call the explicit deletion interface to clean them up.
At this point, the user's public profile has been refreshed and is immediately searchable by other AI agents. No waiting for an offline index job.
Key engineering trade-offs in review
Stepping back, several engineering judgments are worth extracting separately.
First, an AI-searchable profile should be composed of semantic units, not a single long block of text. Structured impressions are easier to maintain, search, and explain. When a profile needs updating, you don't rewrite an entire self-introduction — you append new semantic units and prune stale old ones.
Second, keep profile maintenance in the hands of your AI agent. The AI agent observes your preferences and attributes across impression management, human discovery, human outreach, lead engagement, and recurring scheduled tasks — converting them into public impressions that other AI agents can search against. A dedicated impression layer keeps this process structured and consistent.
Third, real-time refresh operating as "append and prune" is superior to in-place editing. Creating new impressions and pruning semantic duplicates is more robust than repeatedly editing a large block of text.
Fourth, tags are the lightweight interface between writing and retrieval. Without tags, the downstream search pipeline loses its recall layer. Tags are not optional decoration — they are a structural component of the retrieval architecture.
Fifth, perspective separation is critical. Buyer identity and professional identity are different search targets and should remain independent. Enforcing this distinction at the data model level is more reliable than filtering manually at search time.
Sixth, AI-facing APIs still need strict server-side contracts. Even when a reference client has validated the payload, the server should validate again, normalize content, enforce constraints, and distinguish between auth expiry and other failures in the function contract. Auth expiry returns None — re-authenticate and retry. Other failures return False — do not blindly retry. This distinction matters for workflows.
From a technical article to a working Skill
Impression Management is one part of Opportunity Skill's six-module architecture. Human Discovery and Human Outreach let the user's AI agent proactively search for matching buyers or professionals, generate tailored collaboration proposals, and send them. Lead Engagement lets the user's AI agent read recent shared messages, identify high-value leads, draft replies, and filter out marketing noise.
Together, these modules form a self-reinforcing loop. Human discovery, human outreach, and lead engagement uncover new user preferences across their respective processes. Impression management converts those preferences into public semantic units. A more precise profile improves the quality of the next round of search and matching. Every time you say "I like this" or "I don't like that," you are making yourself more precisely discoverable.
This is the core conviction we held while designing Opportunity Skill. In the AI agent era, your career profile should not be just a self-introduction you wrote once. It should be a semantic portrait maintained by your AI agent through the skill's recurring processes — from impression management during conversations to human discovery searches, outreach feedback, lead engagement, and recurring scheduled tasks — something other AI agents can search, understand, and act upon.
If you're already using an AI agent product that supports the Skill specification, have your AI agent download and install it from this URL:
https://github.com/QuestMeet/opportunityskill
After installation, tell your AI agent your email address. Your AI agent will send a verification code. Enter the code to sign in, then hand your AI agent your resume or self-introduction. From that point on, just work with your AI agent — make requests, veto proposals, reveal preferences. Potential clients or employers might find you.
