Being built
Anticipy
Engineering Anticipy across apps, AI, and prototype hardware.
- My role
- Founding Software Engineer at Anticipation Labs
- Period
- Current
- Focus
- Product engineering · AI workflows · Mobile / wearable validation
My contribution spans connected-app reliability, private AI workflows, native-client validation, and wearable bring-up. I set priorities and acceptance criteria, directed AI-assisted implementation and review, coordinated releases, and personally tested phones and prototype hardware.
The product / the work around it
A useful journey
crosses boundaries.
Anticipy is an AI wearable being built to turn spoken intentions into actions through connected software, with the person's approval. Making that useful involves the whole journey: authorization, clear permissions, dependable software, and the device in someone's hand.Visit Anticipy anticipy.ai ↗
My part, and the collaboration.
My contribution
I set requirements and repair priorities, defined privacy and release conditions, coordinated implementation and reviews, and supplied hands-on phone and hardware observations.
AI-assisted engineering
Claude and Codex contributed substantially to implementation, investigations, tests, documentation, and reviews under my direction. The selected work-email prototype was implemented with Codex and bounded agents.
Team foundation
The existing product, workflow and memory engines, native apps, browser engine, and hardware designs were team foundations. My contribution extended that work; it was not a solo product build.
01 / Connected-app reliability
A connection must finish the journey.
Navigation correction deployedA successful server response still left a person stranded at a consent page. The useful test was whether the browser could reach the provider and retry without starting a different authorization.
My part
I prioritized the connection failure, brought actual phone observations into the investigation, and required browser-tested release evidence. Claude and Codex handled diagnosis, implementation, and review; I later checked a Gmail retrieval task myself.
The decision
Preserve consent and expiry while reusing the saved provider attempt. Test the entire browser redirect path, including the hop the first fixture missed.
Explanatory walkthrough / no account connection
A green response was not the destination.
The server returned a successful redirect, but the browser still stopped before provider sign-in. A fixture ending at the first hop missed the real failure.
Follow the path a person actually takes.
The corrected flow preserved consent and reached the provider's sign-in page. The release test stopped before granting a real account.
Resume the attempt. Keep its boundaries.
Back, reload, and retry reused the existing provider attempt. Retry did not create a fresh authorization or extend its lifetime.
What the evidence established
The navigation correction was deployed and verified through Google and Notion sign-in screens. Separately, I reported one successful Gmail read-and-summary task.
Where that evidence stops
This establishes a specific repaired navigation path, not completion of every connector, phone flow, or write action.
02 / Private AI workflows
Useful AI starts with a source you chose.
Locally validated prototypeA work-preparation prototype needed to turn one deliberately selected source into an inspectable brief, without quietly borrowing personal memory, an entire inbox, or permission to act.
My part
I approved the source-to-brief journey and its consent, spending, cancellation, and retention boundaries. Claude and Codex divided backend, web, and integration work, with independent review before the pieces were joined.
The decision
Bind processing to the selected source and current authority. Admit each actual model request against spending limits, and reject late results after cancellation or revoked consent.
Illustrative local prototype walkthrough / invented source / no AI calls
01 / One selected source
Launch review note
Prepare a launch review. Mira owns the draft. Review the launch checklist on Thursday. No launch decision has been made.
Fictional team and content. Nothing is uploaded or stored.
02 / Deliberate processing
Only the selected note.
A person explicitly consents to processing this source. The example uses no personal memory or external actions.
03 / Inspect the result
- Review the launch checklist on Thursday.
Source: “Review the launch checklist on Thursday.”
- Mira owns the draft.
Source: “Mira owns the draft.”
- A launch decision is still open.
Source: “No launch decision has been made.”
Cancellation clears the result and prevents a late response from restoring it. This is a fixed explanatory example; the actual hosted account preview had AI processing disabled.
What the evidence established
The integrated local prototype produced source-backed briefs and exercised identity, privacy, budget, and lifecycle behavior. A separate account preview was deployed with AI processing disabled.
Where that evidence stops
This is a locally validated prototype. Live work-email activation and a live AI service were not established by the account preview.
03 / Browser-agent privacy
Check what leaves, not just what appears.
Locally validated repairProtecting a field in the final answer is too late if its value already entered a model request. The acceptance boundary belonged at acquisition and capture.
My part
I required protected-field handling, capture-boundary checks, and synthetic canaries in actual serialized requests and logs. Agents implemented and reviewed the changes against the existing browser workflows.
The decision
Withhold protected values while keeping consented workflows usable. Repair regressions rather than changing the older tests to make a new guard look successful.
Synthetic illustration / no real credentials or live capture
At the model-input boundary
- Task
- Review a draft
- Protected value
- [value withheld]
- Control
- Continue
Keep the task. Withhold the protected value.
The acceptance test inspected synthetic canaries in actual serialized requests. This simplified illustration shows the intended boundary; it is not a live security test.
What the evidence established
Real-browser fixtures and a narrower installed-extension check exercised protected-field acquisition and outgoing model payloads. The recorded final checks passed within that defined scope.
Where that evidence stops
Bounded synthetic evidence is not universal credential safety. This account omits private diagnostics and does not claim that all browser or native surfaces were covered.
Beyond the three stories
The breadth
of the work.
Twelve contributions, with personal scope and delivery status kept in view. Open a field note for the problem, decision, and outcome.
01Connected-app recoveryConnections / Deployed correction
- The problem
- A person could reach consent but fail to reach the connected service.
- My part
- Prioritized the failure, supplied phone observations, and directed AI-assisted repair and release validation.
- The decision
- Reuse the authorized attempt on retry while preserving expiry and ownership.
- The result
- Browser-navigation correction deployed; one successful Gmail retrieval was personally reported.
02Privacy at captureConnections / Locally validated
- The problem
- Protected fields can leak before a model produces an answer.
- My part
- Set the capture-boundary acceptance standard and required actual-payload checks.
- The decision
- Withhold protected values without broadly refusing useful consented workflows.
- The result
- Bounded real-browser and extension fixtures validated the repair; universal protection is not claimed.
03One task, consistent authorityConnections / Locally validated
- The problem
- Clients and services could disagree about readiness, accounts, permissions, and receipts.
- My part
- Required integrated user-journey proof and honest capability labels.
- The decision
- A saved permission choice does not create an available capability.
- The result
- Local integration repairs covered task evidence, account ambiguity, cancellation, and leases; not every repair was traced to a release.
04Native-client validationDevices / Released · bounded checks
- The problem
- Listening, stopped, connected, and ready need to mean the same thing on the actual device.
- My part
- Directed release order, installed and exercised phone builds, and reported observed behavior.
- The decision
- Explicit Stop must remain stopped; a browser escape path must preserve consent.
- The result
- Native artifacts were released with bounded phone/Mac checks. Wider background and connector acceptance remained incomplete.
05Wearable bench bring-upDevices / Prototype · in progress
- The problem
- Installing firmware is only one step toward a functioning prototype.
- My part
- Swapped physical units, operated USB/reset/pairing, and supplied readiness and audio observations.
- The decision
- Identify each device, preserve recovery, then verify installation and readback.
- The result
- Installation and recovery were verified on individual prototypes; audio, readiness, and pairing qualification remained incomplete.
06Identity and organizationsPrivate AI / Local foundation · preview
- The problem
- Adding a work organization must not expose someone's personal data to colleagues.
- My part
- Directed isolated implementation and review while preserving the existing personal product.
- The decision
- Membership is not permission to read another person's private content.
- The result
- Identity, invitations, sessions, and erasure behavior were validated locally. Selected account behavior reached a separate preview.
07Source-backed preparationPrivate AI / Locally validated prototype
- The problem
- A private brief needs an explicit source and inspectable reasoning context.
- My part
- Approved the note, consent, brief, source inspection, and cancellation journey.
- The decision
- Use only the specifically selected source; no silent personal-memory bridge or external actions.
- The result
- An integrated local flow produced private briefs with bound citations and receipts; hosted AI processing remained off.
08Spending and lifecycle limitsPrivate AI / Locally validated
- The problem
- Retries, timeouts, and late results can escape a simplistic request counter.
- My part
- Set bounded spending authority and required visible cancellation and retention behavior.
- The decision
- Admit each actual request; keep uncertain charges reserved and reject stale results.
- The result
- Budget and lifecycle behavior was exercised locally. No measured production savings or complete backup-erasure claim.
09A deliberately selected emailPrivate AI / Prototype · live activation pending
- The problem
- Connecting a mailbox must not silently import an entire inbox.
- My part
- Continued the bounded source milestone with Codex and review agents.
- The decision
- Confirm the work identity and select one plain-text message; no background ingestion or mail sending.
- The result
- Offline integration covered selection, privacy eviction, and revocation. Live work-email activation remained blocked.
10Release evidence and isolationDelivery / Bounded release delivered
- The problem
- Several services and devices make it easy to confuse tested code with a delivered experience.
- My part
- Set release order, preservation requirements, spending boundaries, and artifact verification expectations.
- The decision
- Keep new services and data separate; verify the deployed artifact and retain a compatible rollback.
- The result
- A separate account preview and disabled runtime were released. Intended CI savings were not measured financial results.
11The Fellowship front doorDelivery / Fellowship coming soon
- The problem
- Prospective applicants needed a clear public route into the team.
- My part
- Contributed the responsive redesign, application navigation, asset verification, and deployment follow-through.
- The decision
- Use a clear approved application destination and preserve the inherited backend.
- The result
- The responsive recruiting experience and application navigation were prepared. Fellowship coming soon; it is not fully published yet. Earlier repository, copy, and application infrastructure were team work.
12Direction and coordinationDelivery / Ongoing contribution
- The problem
- Parallel work needs clear priorities and an honest definition of done.
- My part
- Set acceptance conditions, coordinated Claude/Codex work, controlled release authority, and personally tested devices.
- The decision
- Challenge “connected,” “merged,” and “installed” until the relevant user behavior is demonstrated.
- The result
- Bounded implementation stages, reviews, releases, and unresolved findings stayed explicit. This does not imply sole architecture authorship.
Evidence, at the right level
Installed is a step.
Useful is the test.
The connector navigation correction shipped. Fellowship coming soon; the recruiting experience is not fully published yet. The private AI flow was locally validated; its separate hosted account preview had processing disabled. Native artifacts received bounded device checks, while wearable qualification remained in progress.
- ✓Install & recover
Verified on individual prototypes
- ○Pair & read status
Partial phone integration
- ○Audio & transcript
Qualification incomplete
Beyond implementation
A small team needs
more than code.
Alongside engineering, I supported early operations, the Fellowship recruiting experience, and investor outreach and introductions to angels and venture investors. Company travel was part of that broader contribution.
The Fellowship work includes a clearer application front door and responsive presentation, built on earlier team infrastructure. The experience is not fully published yet.
Fellowship coming soon
Sources & context
The work, with its context.
This account draws on my project records and first-hand involvement. The engineering outcomes below describe recorded checkpoints, not fresh tests or broad customer adoption. Internal records stay private; the links here provide public product context.
- Anticipy ↗
Public product context; not a claim of authorship of the entire product.
- Anticipation Labs ↗
The team behind Anticipy.
A next conversation
Have something
in mind?
I’d like to hear what you’re building and where I could contribute.
Contact about opportunities tejas.kaushik@outlook.com