Inspiration

Idea is coming from the time doing interviews and applying for jobs and sometimes you don't feel really prepared or you can get stuck and not express yourself correctly. So the idea was that you can bridge that gap of expression. You can find your self applying for jobs and sometimes you don't feel really prepared or you can get stuck and not express yourself correctly as the interviews compress years of experience into a short, stressful conversation. Existing AI assistants can make that worse when they invent experience, hide that AI is involved, retain sensitive material, or act without the owner's control. Presence explores a different model: a disclosed AI avatar that can represent only one consenting owner, only from approved professional knowledge, while that owner remains present and able to stop it immediately.

What it does

Presence is a local-first, Windows-first AI interview avatar studio. An owner can prepare an approved profile from a resume, LinkedIn facts, personal context, speaking style, boundaries, portrait, and disclosure recording. The studio separates verified owner facts from untrusted job requirements, supports owner-present practice with OpenAI Realtime, shows a minimized grounding trace, and routes disclosed output through an OBS path or an engineered Windows Media Foundation virtual-camera path.

It is your personal AI avatar assistant for practicing interviews process, by following the best practices. This is regarding interview steps how you should present yourself, how you should explain your experience, how to use star methodology etc. You can practice, you will get review, scoring, suggestions and it will point into what to improve in your posture discussion and presentation.

How we built it

The application uses React, TypeScript, Vite, Express, Electron, OpenAI Realtime over WebRTC, LiveKit, Tavus, and Windows Media Foundation helpers. Sensitive owner content is stored in an AES-256-GCM encrypted local vault protected by the Windows current-user context. Native process-loopback and virtual-camera components keep media in memory and expose narrow, fixed operations to the Electron renderer.

Codex with GPT-5.6 was used throughout the primary implementation task to translate the brief into staged MVP1/MVP2 boundaries, implement the product and native-media paths, construct deterministic safety and lifecycle tests, debug failures, and write operator documentation. The owner made the final product, consent, privacy, and release-boundary decisions.

Challenges

  • Making disclosure and consent runtime requirements rather than policy text.
  • Keeping owner facts separate from untrusted role requirements and participant speech.
  • Making provider cleanup and Emergency Stop fail closed across crashes and uncertain network state.
  • Carrying selected-process audio and disclosed frames through narrow Windows-native boundaries without persisting raw media.
  • Describing a strong engineering prototype honestly while final biometric enrollment and meeting-app acceptance remain owner-dependent.

Accomplishments

  • A working local-first desktop studio with profile, consent, disclosure, rehearsal, grounding, and emergency controls.
  • Direct OpenAI Realtime speech-to-speech plus bounded provider and LiveKit/Tavus solo-rehearsal paths.
  • Windows selected-process audio and Media Foundation virtual-camera engineering with stopped-output disclosure.
  • Deterministic adversarial, application, desktop/native, and Electron end-to-end coverage.
  • Explicit documentation of what is implemented, what is tested, and what still requires real owner/provider evidence.

What we learned

Safety properties become dependable only when they are encoded into session creation, media routing, cleanup, and UI state. A disclosure banner is not enough if media can start before disclosure completes. A Stop button is not enough if cleanup uncertainty is reported as success. Provenance also has to be visible: job requirements can guide questions, but they must never become evidence that the owner has experience they did not provide.

What's next

The next milestone is owner-controlled enrollment and credentialed provider validation, followed by UAC virtual-camera registration and an acceptance matrix in Camera, Teams, Zoom, and Chromium. After that: signed installer and updater work, measured two-party/soak evidence, stronger identity and liveness controls, and a separate multi-user security design before any SaaS deployment.

Built With

Share this project:

Updates