Conference catalogs are useful until they become another backlog.
When I checked the AWS re:Invent 2026 catalog, it contained 444 sessions. I wanted every Level 300 and 400 session relevant to my work, but I did not want to read hundreds of cards and click the favorite button multiple times.
I used ChatGPT to turn the catalog into a profile-based shortlist and then add the selected sessions to my AWS event favorites. This article documents the complete workflow, including the prompts, validation checks, browser automation, and the part that initially failed.
The result in my case was:
- 444 sessions in the catalog
- 412 sessions after applying the Level 300 and 400 filter
- 89 sessions relevant to my work
- 30 sessions ranked as the highest priority
The numbers are only a snapshot from July 18, 2026. The catalog will change. The workflow is the reusable part.
Also, all of my favorites are not an agenda. They are a searchable shortlist. I will make the real agenda later, once AWS publishes the full schedule and session conflicts become visible.
Why a personal relevance profile comes first
The obvious first prompt would be: "Pick the best sessions for me."
That is too vague. ChatGPT may know your role from earlier conversations, but some details may be outdated, inferred, or simply wrong. If the model starts with a weak profile, it can produce a polished but generic list.
I first made ChatGPT state what it knew about me and explain how each fact should affect session selection. This separated confirmed information from assumptions before the catalog influenced the answer.
Use this as the first prompt in a new chat:
Before inspecting any conference catalog, validate what you currently know about me and create a Conference Relevance Profile.
Consult the personal context, memories, files, and conversation history that are legitimately available to you. Do not invent details or turn assumptions into facts.
Cover:
1. My current role and responsibilities
2. My strongest technical skills
3. Technologies, platforms, and programming languages I use
4. Architecture areas relevant to my work
5. My level of experience
6. Projects or problems I appear to be working on
7. Technologies I want to learn
8. Strategic interests that could affect conference-session selection
9. Topics that are probably irrelevant to me
10. Any preferences or constraints that should influence the selection
For every statement, label it as:
- Confirmed
- Reasonably inferred
- Unknown
Explain briefly how each confirmed or inferred item affects session relevance.
If important information is missing, ask no more than five focused questions. Finish with a concise Session Selection Profile that I can edit and approve.
Do not inspect the conference catalog yet. Wait for me to approve or correct the profile.
Review the result. Correct wrong assumptions and add missing interests. Do not skip this step just because the profile looks mostly right.
My approved profile prioritized:
- AWS Serverless and event-driven architecture
- Agentic AI and production AI engineering
- Platform engineering and developer experience
- Amazon ECS and container operations
- Streaming, Kafka, Flink, DynamoDB, and real-time data
- Media and sports workloads
- Architecture trade-offs, resilience, security, and cost
I also made the exclusions explicit. Generic migrations, introductory sessions, SAP, Oracle, VMware, model training hardware, and narrow industry sessions were out unless they had a direct connection to my work.
Open the catalog and let the user handle authentication
Next, open the official AWS re:Invent event catalog.
If your ChatGPT version provides an integrated browser, tell it to use that browser. If AWS asks you to sign in, take control and complete the login yourself. Never give ChatGPT your password, MFA code, session cookie, or access token.
This prompt makes the boundary clear:
Use my approved Conference Relevance Profile for this task.
Open the official AWS re:Invent event catalog in the integrated ChatGPT browser. You are authorized to open the catalog, read its session content, apply catalog filters, and navigate public catalog pages.
If authentication is required, pause and let me sign in manually in the opened browser. Do not ask for or handle my password, MFA code, cookies, or tokens. Continue only after I confirm that login is complete.
Do not select or favorite anything yet.
Not every ChatGPT surface supports browser control or authenticated browsing. If yours does not, open the catalog in your normal browser and save or upload the HTML page. That route still works, but it needs an additional completeness check.
Verify that the catalog data is complete
This was the most important technical check in my run.
The saved HTML reported 444 events, but it contained only the first 50 rendered session cards. The site loads more cards on the client side, so parsing the file without checking the count would have silently ignored almost 90 percent of the catalog.
After the Level 300 and 400 filter was applied, the live catalog exposed 412 matching sessions. ChatGPT loaded all results and compared the extracted count with the number shown by the catalog.
Use this prompt with either the live catalog or an uploaded HTML file:
Inspect the complete conference catalog and verify the input before selecting sessions.
Requirements:
- Read the total session count shown by the catalog.
- Apply only Level 300 and Level 400 as mandatory filters.
- Load all results, including lazy-loaded or paginated cards.
- Compare the number of extracted cards with the number reported by the UI.
- If an uploaded HTML file contains only the initially rendered cards, do not treat it as the complete catalog.
- Use the integrated browser and the catalog's public client-rendered data where available.
- Report any count mismatch or visibility gap explicitly.
- Do not infer missing sessions and do not claim complete coverage unless the counts can be reconciled.
Stop before relevance scoring and show me the validation result.
Do not accept an answer such as "I reviewed the catalog" without counts. For dynamic web applications, the count is the evidence that the model actually reached the full result set.
Filter by hard requirements, then score relevance
Once the input was validated, I asked ChatGPT to apply two different kinds of criteria:
- Hard filters: Level 300 or 400 only.
- Relevance scoring: how directly each session matched my approved profile.
Keeping these separate matters. A relevant Level 200 session still fails the acceptance criteria. A Level 400 session is not automatically relevant just because it is advanced.
Here is the selection prompt:
Using the validated catalog and my approved Conference Relevance Profile, select all sessions relevant to me.
Acceptance criteria:
- Include only Level 300 or Level 400 sessions.
- Evaluate every session that passes the level filter.
- Use the title and full description, not keyword matching alone.
- Include a session only when you can explain its direct relevance to my role, current work, or stated learning goals.
- Exclude generic, introductory, vendor-marketing, and unrelated industry sessions.
- Keep borderline sessions out unless there is a concrete technical reason to include them.
- Do not recommend EKS merely because it is a platform-engineering topic. Include an EKS session only if it provides a useful comparison with my ECS work or covers a capability I need to evaluate.
- Deduplicate by session code.
For each selected session return:
- Session code
- Level
- Format
- Exact title
- Relevance category
- One short reason for inclusion
Then split the result into:
1. Reserve first: the strongest matches
2. Also relevant: useful sessions with lower priority
Finally report:
- Total catalog entries
- Entries passing the level filter
- Selected sessions
- Reserve-first sessions
- Excluded topic groups
Do not add favorites yet.
In my case, ChatGPT selected 89 sessions and put 30 into the first-priority group. It retained a few EKS sessions for an honest ECS-versus-EKS platform comparison, not because every container workload needs Kubernetes.
That distinction is useful. A recommendation system should help you test your current architecture decisions, not just mirror your existing preferences.
Review the shortlist before changing anything
Before touching the AWS event account, I reviewed the result by category:
- Architecture, serverless, and event-driven systems
- Agentic AI engineering
- Platform engineering and ECS
- Streaming, data, and media
- Resilience, isolation, security, and cost
I also checked that every item had a session code. Titles can change slightly, and some titles look similar. The session code is the stable allow-list for the next step.
Use this validation prompt:
Validate the selected session list before any browser changes.
- Confirm that every item has one unique session code.
- Report duplicate codes, missing codes, or malformed codes.
- Confirm that every item is Level 300 or 400.
- Return a plain, space-separated allow-list of session codes.
- State the exact number of unique codes.
Do not open or modify my favorites yet.
Save this allow-list. It prevents the browser step from turning into an open-ended "click anything relevant" instruction.
Add the sessions with the integrated browser
Favorites modify your event account, even though the action is reversible. I used a separate prompt with a strict sequence: discover, validate, confirm, mutate, verify.
Open the official AWS re:Invent event catalog in the integrated ChatGPT browser.
If login is required, pause and let me sign in manually. Never request or handle my credentials, MFA code, cookies, or tokens.
Use the approved session-code allow-list from the previous step. Do not add any session that is not in that list.
Before making changes:
1. Load all catalog results.
2. Locate every selected session code.
3. Read the current favorite state for each one.
4. Report any missing or ambiguous code.
5. Make no changes if at least one code cannot be resolved.
6. Ask for one final confirmation and state the number of sessions that will be added.
After I confirm:
- Add only sessions from the allow-list.
- Skip sessions that are already favorites.
- Change one session at a time.
- Wait until the UI confirms the favorite state before continuing.
- Stop on the first action that cannot be confirmed.
- Do not unfavorite anything.
At the end, report four counts:
- Newly added
- Already favorited
- Missing
- Failed or unconfirmed
If the browser can perform the actions, keep the tab open until it reports completion. Do not interrupt a running batch just because the UI looks idle for a few seconds.
Fallback: run a reviewed script in your signed-in browser
My ChatGPT environment could read the catalog but could not operate the authenticated AWS session. The fallback was a small script executed in the developer console of my already signed-in browser.
This script does not need your password or call a private API directly. It uses the same favorite buttons shown in the page. It first loads all results, verifies that every requested session exists, asks for confirmation, skips existing favorites, and stops if a click cannot be confirmed.
Open the official catalog, sign in, apply the Level 300 and 400 filters, then open Developer Tools and select Console. Replace the example codes below with the allow-list generated for you.
Review the script before running it. Only run it on registration.awsevents.com. Browser console code has the same access to the page as you do.
(async () => {
const codes = `
ARC306 ARC314 ARC312
`.trim().split(/\s+/);
if (location.hostname !== "registration.awsevents.com") {
throw new Error("Open the official AWS event catalog before running this script.");
}
const uniqueCodes = [...new Set(codes)];
if (uniqueCodes.length !== codes.length) {
throw new Error("The session-code list contains duplicates.");
}
const pause = ms => new Promise(resolve => setTimeout(resolve, ms));
const cards = () =>
[...document.querySelectorAll("li.catalog-result.session-result")];
// Load every lazy-loaded result.
for (let round = 0; round < 50; round++) {
const more = [...document.querySelectorAll("button.show-more-btn")]
.find(button => !button.disabled && button.offsetParent !== null);
if (!more) break;
const before = cards().length;
more.click();
for (let attempt = 0; attempt < 60; attempt++) {
await pause(250);
if (cards().length > before) break;
}
if (cards().length === before) {
throw new Error("The catalog stopped loading additional sessions.");
}
}
const cardFor = code =>
document.getElementById(code.toLowerCase())
?.closest("li.catalog-result.session-result");
const buttonFor = code =>
cardFor(code)?.querySelector("button.favorite-session");
const isFavorite = button => Boolean(
button && (
button.getAttribute("aria-pressed") === "true" ||
/unfavorite/i.test(button.getAttribute("aria-label") || "")
)
);
const missing = uniqueCodes.filter(code => !cardFor(code));
if (missing.length) {
throw new Error(`No changes made. Missing sessions: ${missing.join(", ")}`);
}
const toAdd = uniqueCodes.filter(code => !isFavorite(buttonFor(code)));
if (!confirm(
`Found all ${uniqueCodes.length} sessions. ` +
`${toAdd.length} will be added and ` +
`${uniqueCodes.length - toAdd.length} are already favorites. Continue?`
)) {
return;
}
const results = [];
for (const code of uniqueCodes) {
let button = buttonFor(code);
if (!button) {
results.push({ code, status: "favorite button missing" });
break;
}
if (isFavorite(button)) {
results.push({ code, status: "already favorite" });
continue;
}
button.click();
let confirmed = false;
for (let attempt = 0; attempt < 25; attempt++) {
await pause(200);
button = buttonFor(code);
if (isFavorite(button)) {
confirmed = true;
break;
}
}
results.push({
code,
status: confirmed ? "added" : "not confirmed; stopped"
});
if (!confirmed) break;
// Avoid sending a burst of UI actions.
await pause(350);
}
console.table(results);
const added = results.filter(result => result.status === "added").length;
const existing = results.filter(
result => result.status === "already favorite"
).length;
const failed = results.filter(
result => !["added", "already favorite"].includes(result.status)
).length;
console.log({
requested: uniqueCodes.length,
added,
alreadyFavorite: existing,
failed,
confirmedFavorite: added + existing
});
})();
The selectors matched the re:Invent 2026 catalog on July 18, 2026. AWS can change the page structure at any time. If that happens, the script should stop rather than guess, but you will need to update the selectors.
The script is safe to rerun for the same list because it skips sessions that are already favorites.
Verify the final state
Do not treat a successful click as a successful batch. Reload the catalog, switch to the favorites view if available, and verify the session codes again.
You can ask ChatGPT to perform or guide the read-only verification:
Verify the final favorite state against my approved session-code allow-list.
- Reload the official catalog.
- Do not change any favorite state.
- Check every code in the allow-list.
- Report codes confirmed as favorites.
- Report codes that are missing or not favorited.
- Compare the confirmed total with the expected unique-code count.
Do not claim completion if the counts differ.
For large lists, export or copy the final table from the console. It gives you a useful audit trail if the browser loses its session halfway through.
What I would keep from this workflow
The useful part was not simply asking an AI to recommend sessions. Four controls made the result trustworthy:
- The relevance profile was reviewed before the catalog was opened.
- The number of extracted cards was checked against the catalog count.
- Session codes became a fixed allow-list before account changes began.
- Every favorite action had to be confirmed by the UI.
The catalog will grow, session titles will change, and AWS may update the UI. Rerun the selection when the schedule is closer to final. Keep the profile and prompts, but regenerate the shortlist from the current catalog rather than assuming an old list is still complete.
This turns several hours of catalog work into a repeatable review process while keeping the final decisions, authentication, and account changes under your control.
Top comments (1)
This is a good practical use case because the AI is not replacing judgment; it is reducing the pile to something a person can actually review. Shortlisting is often the best place to add automation first.