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
I decide which problems to fix first and what we need to test across connected apps, private AI workflows and prototype devices. I direct AI-assisted engineering, coordinate releases, and test on phones and hardware myself.
The product / the work around it
From intention
to action.
We're building Anticipy, an AI wearable that turns spoken intentions into actions through connected software, with the person's approval. My work goes from the account-connection flow to testing what happens on the actual device.Visit Anticipy anticipy.ai ↗
Repaired the browser path from consent to provider sign-in.
Navigation correction deployedPrivate AIOne selected source, explicit consent, citations, cancellation, and spending limits.
Local prototype · account preview processing disabledBrowser privacyRequired protected-value checks on what actually reaches the model.
Validated within defined browser fixtures
My part, and the collaboration.
My contribution
I set the requirements, defined the privacy checks and release conditions, and coordinated the implementation and reviews.
AI-assisted engineering
Claude and Codex did a lot of the implementation, investigation, testing and documentation under my direction, and also helped review the work. I worked with Codex on the selected work-email prototype.
Team foundation
The team had already built the product foundations: workflow and memory engines, native apps, the browser engine and hardware designs. I built on their work. I didn't build Anticipy on my own.
01 / Connected-app reliability
Getting past the consent page.
Navigation correction deployedThe server reported success, but the person was still stuck on the consent page. We needed to test whether the browser could reach the provider's sign-in page and retry without starting a new authorization.
My part
I made this failure a priority and brought in what I saw on my phone. I required a browser test before release. Claude and Codex did the diagnosis, fix and review, and I later checked a Gmail retrieval task myself.
The decision
Keep the existing consent and expiry when retrying the saved provider attempt. Test the whole browser redirect path, including the step the first test 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 worked
The navigation fix was deployed and checked through the Google and Notion sign-in screens. Separately, I reported one Gmail read-and-summary task that worked.
What these tests don’t show
Those checks cover one repaired navigation path. They don't show that every connector, phone flow or write action works.
02 / Private AI workflows
A brief from one source you chose.
Locally validated prototypeWe wanted a work-preparation prototype that could turn one source you picked into a brief you could check. It couldn't quietly pull in your personal memory or whole inbox, or assume permission to act.
My part
I approved the flow from choosing a source to reading the brief, including the rules for consent, spending, cancellation and keeping data. Claude and Codex split the backend, web and integration work. The pieces were reviewed independently before we joined them.
The decision
Only process the source the person picked, while they still allow it. Check every model request against the spending limit. Discard results that arrive after they've cancelled or withdrawn 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 worked
The combined prototype produced briefs with source citations in local tests. Those tests also checked identity, privacy, spending limits and what happened when work was cancelled or deleted. We deployed a separate account preview with AI processing disabled.
What these tests don’t show
This was tested locally. The account preview didn't activate live work email or a live AI service.
03 / Browser-agent privacy
Check what reaches the model.
Locally validated repairHiding a protected field in the answer is too late if its value already went into a model request. I wanted the checks where the browser first reads and captures the data.
My part
I required protected-field checks using synthetic test values in the actual outgoing requests and logs. AI agents implemented and reviewed the changes against the existing browser workflows.
The decision
Keep protected values out while allowing the workflows a person has consented to. If the change breaks something, fix it. Don't rewrite old tests just to make the new check pass.
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 test checked for synthetic protected values in the outgoing model-request data. This illustration explains that check; it does not run a live security test.
What worked
Tests in a real browser, plus a smaller check on the installed extension, covered how protected fields were read and what reached the model. The final recorded checks passed for those cases.
What these tests don’t show
These checks used synthetic data in a limited setup. They don't prove credentials are safe everywhere. I'm leaving private diagnostics out, and I can't claim every browser or native surface was covered.
Beyond the three stories
More of
the work.
These twelve entries explain the problem, what I did, and how far the work got.
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
Device tests
and unfinished work.
The released native builds had limited phone and Mac checks. On individual wearable prototypes, we verified installation and recovery. Pairing, audio and transcripts still needed more testing before we could call them ready.
- ✓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.
I've also helped with early operations and recruiting, travelled for the company, and made investor introductions. I'm not claiming those introductions raised any funding.
I helped redesign the Fellowship website and application flow using the team’s existing infrastructure. It isn’t fully published yet.
Fellowship coming soon
What I learned
A chance to go to Stan Launchpad.
Hard work pays off. Working on Anticipy gave me the opportunity to go to Stan Launchpad, and I went. That was great.
My account, shared on 12 October 2026.
Sources & context
The work, with its context.
I wrote this from my project records and my own involvement. The results are what we checked at the time, not new tests or proof of customer adoption. Internal records stay private; the public links show the product and the team.
- 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