2026-01-26 08:00:00
For the past year, Model Context Protocol (MCP) has done a lot of maturing - starting as a small open source experiment, it now became a full-fledged protocol that is broadly adopted by the industry at large. You can throw a rock and hit something that somehow integrates MCP.
That being said, one of the more peculiar limitations of MCP has always been the fact that you can’t really do a lot with it beyond text on the wire (which is still extremely useful, to be very clear) - JSON-RPC is a nice little abstraction to ferry a bunch of text-based requests and responses. Anything interactive was usually done with the help of, what I would say, hacks, like sending the URL that a user would have to go to to see a visualization of their data or results of some action (think - Playwright MCP post-test reports).
Starting today, though, the landscape is changing - MCP took another leap by adding support for its first official extension, MCP Apps, a project built on the foundations of the work that the awesome folks at MCP-UI and OpenAI have been carefully nurturing.
You can catch up with my demo video to see it in action:
What’s cool about MCP Apps is that you can already tinker with it in Claude and Visual Studio Code Insiders, with more clients on the way!
Here are a few places for you to check out if you want to get building:
API Documentation QuickstartAnd of course, I would be remiss if I didn’t call out the blog post announcing the release as well as the extensive collection of samples that will show you how to get started quickly.
MCP Apps are nothing other than HTML layered on top of the existing protocol abstractions, so the changes for both server and client implementers are fairly surgical. This will also hopefully make it much easier to adopt within the ecosystem.
For those reading who are a bit more security conscious, I got you covered - because apps run inside a sandboxed iframe controlled by the host, developers don’t have to worry about them escaping their container, accessing the parent page, or doing anything nefarious with cookies.
But - and that’s a big one, the real magic here is the bidirectional flow of data. An MCP App can invoke server tools and receive live updates without developers having to spin up separate infrastructure or deal with transport plumbing themselves. Neat!
The MCP Apps extension is, of course, still under active development. If you are still on the fence if you want to help shape the direction of the protocol, now is the perfect time to get involved.
For bugs or feature requests, the team is tracking everything through GitHub Issues.
For broader discussions about where the project should go or how it fits into existing workflows, there’s a dedicated space in GitHub Discussions.
And hey, if you want to take my biased opinion, this is one of those rare moments where the extension setup is still malleable enough that community feedback can genuinely shape its direction. Come help!
2026-01-17 08:00:00
As an open source project maintainer, one of the things that I often need to do, to the surprise of no one, is triage issues. When doing so, I try to rely as much as possible on automation; however, it’s not always available out-of-the-box for some edge cases.
One such edge case is setting issue types in GitHub. If you are not familiar with it, I am not talking about issue labels, but specifically types.
Typically, I’d use the GitHub CLI for this kind of toil, but as it turns out there is no argument available that allows me to set the type. So, I had to look for creative workarounds.
Issue types are entirely owner-managed. For example, in the PowerToys repo (where I maintain Awake), a maintainer can flag something as a Bug, Feature, or Task.
Now, if I’d ask anyone how they can set types for a given issue, they’d probably guess that they can use gh issues edit, but alas that’s not something I can do. Luckily, the GitHub CLI allows me to also talk directly to the GitHub GraphQL API, which offers way more capabilities than the command line tool.
So, I’ll start by querying the available issue types for the aforementioned PowerToys repository:
gh api graphql -f query='
{
repository(owner: "microsoft", name: "powertoys") {
issueTypes(first: 20) {
nodes {
id
name
description
}
}
}
}'
This will yield a JSON blob like this:
{
"data": {
"repository": {
"issueTypes": {
"nodes": [
{
"id": "IT_kwDOAF3p4s4ACCgE",
"name": "Task",
"description": "A specific piece of work"
},
{
"id": "IT_kwDOAF3p4s4ACCgH",
"name": "Bug",
"description": "An unexpected problem or behavior"
},
{
"id": "IT_kwDOAF3p4s4ACCgK",
"name": "Feature",
"description": "A request, idea, or new functionality"
}
]
}
}
}
}
Not bad. I now have the unique id associated with each issue type. But I don’t just need to get the issue types. I need to be able to set them. To do that, I’m once again going to lean on the GitHub GraphQL API, with the help of mutations. The GitHub GraphQL API uses global node IDs and not the issue numbers (what you see in the web UI) for mutations, meaning I need to retrieve the issue’s node ID first.
Here is the GraphQL query that I need to execute from the GitHub CLI:
gh api graphql -f query='
{
repository(owner: "microsoft", name: "powertoys") {
issue(number: 44644) {
id
title
issueType {
name
}
}
}
}'
If all goes well, this is what I’ll get:
{
"data": {
"repository": {
"issue": {
"id": "I_kwDOCv6UO87iZtnQ",
"title": "Bug report run logs",
"issueType": {
"name": "Bug"
}
}
}
}
}
The id value is all I need. Now, I can use the updateIssue mutation to set the type.
gh api graphql -f query='
mutation {
updateIssue(input: {
id: "I_kwDOCv6UO87iZtnQ",
issueTypeId: "IT_kwDOAF3p4s4ACCgH"
}) {
issue {
number
title
issueType {
name
}
}
}
}'
Notice the issueTypeId - this is where I use the relevant issue type ID from the very first step to set the type.
A successful type assignment operation will result in this JSON output in your terminal:
{
"data": {
"updateIssue": {
"issue": {
"number": 44644,
"title": "Bug report run logs",
"issueType": {
"name": "Bug"
}
}
}
}
}
To remove an issue type from an issue, pass null as the issueTypeId in the GraphQL query above.
It’s a bit more work than I’d like for something this basic, but wrapping these queries in a shell script or a custom CLI extension (that’s for another blog post) makes it easy to integrate into your triage workflow. Hopefully native gh issue edit support comes soon.
2026-01-11 08:00:00
Just a few days ago I wrote about wrapping up my latest Microsoft chapter. I’ve spent the past three years immersed in security, and as of last year alone, quite a bit of Model Context Protocol (MCP). That last part is probably eye-roll-inducing to anyone who’s been following me on LinkedIn.
This work serendipitously led me to what comes next. My next chapter is joining Anthropic (yes, that Anthropic) as a Member of Technical Staff.
Before we go further, I just wanted to mention how much I love the work behind Calvin and Hobbes. This particular strip from the very last installment of the comic (published on December 31st, 1995) feels especially fitting for this moment. There’s something different about stepping into a new role at the start of a new year - a blank canvas, much like a coat of fresh snow (which, apparently we’re not getting much of in the PNW this year).
The switch to Anthropic was not super-spontaneous. After a year working on MCP as a member of the MCP Steering Committee and then a Core Maintainer focused on auth and security, I really grew to appreciate the effort that Anthropic was putting into organically scaling what has now become an industry standard for connecting data and applications to Large Language Models (LLMs). I also had a few informal conversations with Anthropic folks, learning about their roadmap, culture, and aspirations.
Then, a chance to work closely with the Anthropic MCP crew came up. The opportunity to help build MCP from inside felt like such a surprisingly natural fit that I did a double take and asked my wife, “Is this even a real job?” As it turns out, it was! It also helps that I’m already a huge fan of the Claude family of models (my go-to for all engineering work), so the decision to go work with folks whose product I am already using practically daily was easy.
Ultimately, the decision to join was grounded in a few core beliefs that I hold:
At Anthropic, my immediate focus will be, you guessed it, on MCP. If you’re already part of the contributor community, I’m sorry, but you’ll be seeing more of me. If you’re part of the broader MCP ecosystem, I am excited to collaborate with you on making the protocol even more mature!
As the world moves to agent-first workflows, I realize that there is so much more to be done to nurture and grow MCP for this paradigm shift. I strongly believe that Anthropic is the place to do it - not just because they created MCP, but because they’re deeply committed to building AI with safety in mind. As agents gain more autonomy and connect to more systems, that commitment becomes non-negotiable.
This career change is a calculated bet on the impact of AI on the world, and specifically on something near and dear to me: software engineering and the need to connect systems to make them work well together (which, as you know, is the whole idea behind MCP). As models become ubiquitous “appliances” in modern software, it will be more important than ever to make sure they interoperate safely, securely, and in a scalable way with other systems, services, APIs, and applications. My mental calculus here was simple: even if I can contribute just a tiny bit to accelerate MCP adoption, help improve its security posture and readiness for more real-world scenarios, there is no better place to do that than at its birthplace.
I am also excited to work more closely with David Soria-Parra, Jerome Swannack, Paul Carleton, Basil Hosmer, Inna Harper, Weynab Maher, and quite a few others at Anthropic who are building out the protocol and the broader agentic AI ecosystem.
It’s hard to put into words how I feel about this change - I am nervous and excited, cautiously optimistic and yet ready to jump in and start contributing. I am positive that working at Anthropic will be transformative, and I am looking forward to both learning from some of the most talented folks in the industry as well as helping steer us to a future where AI is safe, accessible, and beneficial at scale.
Let’s shucking go!
2026-01-09 08:00:00
Three years and a quarter ago, my hiring manager asked me - “How do I know you’re not going to leave Microsoft again if we hire you?” It’s not an unfair question to ask, especially considering that I was going for my third stint at the company. My answer to that was pretty simple, at least from my vantage point - I can never guarantee this, but I will give it my all to build the best product imaginable because I live and breathe developer experience.
Three years and a quarter - that’s how long it took me to decide that it was time to close this chapter of my Microsoft adventure. Today is my last day at the company, and next week I’ll be diving headfirst into a new challenge.
It’s more than a bit of a bittersweet moment, because the team and the role I was in were fantastic. After being there for the past year (the previous two I spent working in Microsoft Security), I can tell you that Developer Division, or DevDiv as folks called it before it got folded into CoreAI, is an extremely fun place to work. I’m not just saying this to be nice - it really is the place to be at Microsoft to ship fast, learn fast, and be on the cutting edge of what developers use every day.
This was my dream org since I joined Microsoft. We’re talking about the birthplace of Visual Studio, Visual Studio Code, C# (and the .NET platform), TypeScript, Visual Basic (that’s what I started with way, way back), and so much more. Could an absolute engineering geek ask for a better place to be?
It’s something I always aspired to be a part of, and through a mix of luck and a whole lot of very much unrelated and very much unexpected stress, this dream became reality in the very first weeks of 2025.
Since January of last year I had the privilege of tackling many interesting problems, like helping figure out the adoption blockers for GitHub Copilot, charting out the path for better authentication and authorization integration in our IDEs (I guess I put my Entra ID knowledge to use here too), building quite a few conference prototypes and demos, training the internal Model Context Protocol (MCP) security muscle, and most recently - launching GitHub Spec Kit, which blasted past 61,000 stars on GitHub. Like I said, this org is lots of fun, and I had a lot of agency to do things that are impactful.
Oh yeah, and did I mention that GitHub Spec Kit is the second most starred repository in the entire GitHub org? Talk about a little experiment getting out of hand.
But as with any career step, sometimes the chutes and ladders drop us in wildly unexpected directions. That’s exactly what happened here. The timing is a bit odd, considering that just this fall I shifted roles, but I knew deep down that the change was something I had to do - at least to try and apply my skills at a different scale. I’ve done moves like this in the past, but this one feels particularly poignant - and yet, very exciting.
I wanted to take a moment in this somewhat long-winded blog post to express my immense gratitude to a few folks who were absolutely instrumental to my career in the past few years and even way before then.
It would be a grave disservice to not first call out just how impactful the work of Amanda Silver is on everything that I did at Microsoft and even outside of it before coming to DevDiv. People might not know just how big of an influence she is on cultural, technical, and product direction in Microsoft’s developer ecosystem - she truly is second to none when it comes to understanding developers. In my eyes, Amanda is the Developer Division. I owe her my position in DevDiv and CoreAI as a whole - she did the most for me of any managers or mentors in the past half decade, and I know a lot of folks who feel the same way. My biggest reservation about leaving Microsoft was that I won’t get to work with Amanda on the same team.
A few other folks that I want to individually call out for all they did to help shape my latest Microsoft tour of duty:
Also, very special shout-out goes also to some of the most amazing folks that I had the privilege of crossing paths with, who more than once helped me beyond what one could even ask for: Julia Kasper, Annaji Sharma Ganti, Tyler Leonhardt, Mandy Whaley, Scott McMurray (Halo Studios), Diviyan Matheendran (Halo Studios), Nancy Anderson, Jeff Carnahan (Halo Studios), Toby Padilla, Mike Kistler, Lutz Roeder, Josh Free, Peter Marcu, Peter Maytak, Gladwin Johnson, Neha Bharghava, Keegan Caruso, Josh Lozensky, Kelly Song, Bogdan Gavril, Ray Luo, Travis Walker, Adrian Frei, Iulian Cociug, Chris Mann, Christopher Scott, Saeed Akhter, Stephen Halter, Stephen Toub, David Fowler, Joe Binder, Paul Yuknewicz, Shayne Boyer, Maddie Montaquila, Pierce Boggan, Maria Naggaga, Ernie Booth, Cassie Breviu, Eric Hollenbery, Hemory Phifer, Matt Ellis, Matthew Reyermann, Martin Woodward, Mario Rodriguez, Chuck Lantz, Tim Heuer, Denizhan Yigitbas, Evan Boyle, and a massive fleet of other Microsofties and Hubbers who I learned from every day.
And of course, shout-out to the Microsoft-internal MCP Security Core Crew - the “deep into everything security” people I’ve been collaborating with in the past year to make sure that we improve the MCP security posture inside Microsoft and outside of it (I think we did a pretty solid job): Barry Dorrans, Alex Sklar, Matthew Henderson, Nazmus Sakib, Stuart Schaefer, Tolga Acar, Diana Smetters, Pam Dingle, and David Parks.
It also wouldn’t be a farewell post without a stereotypical “badge on the laptop” photo - I always found the implied tradition somewhat funny, as if we’re cops handing in our badge and gun.
If there’s one thing I’ve learned in my career - the tech industry is a ridiculously small space. If we worked or otherwise collaborated together, I am sure that we’ll run into each other again many times in the future. Guaranteed.
Will share more on the next adventure soon!
2025-12-14 08:00:00
Well, well, well - as 2025 draws to a close, I thought I’d resurrect an old trend and start writing yearly summaries again. I also went ahead and picked a theme for the past 365-ish days. I can’t help but call this the year of Model Context Protocol (MCP).
Remember when I said that June was the month of MCP? How naive! Little did I know that for me personally this entire year became almost entirely consumed by all things MCP. That was, hands down, one of the highlights of 2025. Not the only one, to be clear, but probably the most significant and impactful.
This blog post is a bit of a reflection on the past twelve months, so if you’re looking for some groundbreaking MCP developments, you will have to check back in January.
What’s funny about this kind of “looking back” post is that I used to do yearly reflection posts just shy of a decade back, and then kind of… stopped. What’s old is new again, and now that the work dies down before the end of the year, I can sit down, brew some decaf, and get my thoughts together.
I am writing this post just having visited San Francisco. I was there for three reasons, all obviously related to MCP.
First and foremost, to catch up with MCP Core Maintainers about transports. Then, to join my friends at Anthropic for the celebration of MCP joining the Agentic AI Foundation, and after that - to deliver a lightning talk at MCP Night 3.0, hosted by WorkOS, who graciously invited me to speak about some new spec developments.
The MCP Core Maintainer meeting was spurred by a strong desire to discuss the future of transports within the protocol. Believe it or not, just because we have STDIO and Streamable HTTP doesn’t mean that the work is done. More on this in a future discussion, but I will just say that there is a lot of work happening behind the scenes to make MCP scale better in production scenarios.
You might’ve noticed from some past musings that when there is a major topic that warrants a debate, MCP Core Maintainers just meet to talk about it in person. Does this remind you of any other open-source project that operates at scale? Jokes aside, we did actually have a fairly productive discussion that I think will be reflected nicely in a future update of the MCP specification (the last one was this November).
Can’t complain about the sunny views we had from the office either.
It’s also worth mentioning that the discussion we had comes on the heels of the protocol maturing quickly over the past year. If you’ve been looking inside our Discord server, you might’ve noticed that there are groups of folks with very extensive expertise in various domains who are deeply impactful when it comes to the MCP design and architecture. That’s a good thing.
We ended up with a handful of “knowledge niches” - pockets of the community that have a strong influence on protocol direction from very specialized vantage points. They help shape such aspects as transports, extensibility, security (this includes authentication and authorization), SDKs, and much more. The high-level maintainer groups are then tasked with shepherding the set of proposals rather than come up with them all alone. That task would be untenable for a project that picked up as much steam as MCP did in the past year.
In between all the maintainer work, a few of us made our way to the Anthropic HQ to celebrate the launch of the Agentic AI Foundation. You can check out the announcements from Anthropic, David Soria Parra, and GitHub to learn more.
Yours truly was also part of a mini-documentary run by GitHub related to this very occasion!
Anthropic HQ is also where I got to meet the famous Claudius, and it’s as cool a concept as you can imagine.
Now, on MCP Night during the same week, I somehow ended up being together with people who are much (much) smarter than me. I mean, just look at this line-up and tell me I am wrong.
My little five-minute talk focused on the introduction of Client ID Metadata Documents (CIMD) into the MCP specification and how it reflects in actual product usage, with Visual Studio Code as the example client. Despite that we only have two well-known MCP servers testing CIMD, it’s so exciting to see it light up in a real app.
Frankly, though, being there was not just about the talk - I got to catch up with so many community members who contributed to the protocol throughout the year. Informal chats like this are a great opportunity to learn about what excites and worries people about MCP. As it turns out - moving away from Dynamic Client Registration (DCR) is what excites people. Go figure, it’s not as intuitive to implement as one may think.
In hindsight, I am so thankful that I got involved with MCP earlier this year. From a little effort to update the authorization specification to becoming a Core Maintainer, it turned into one of the most fulfilling collaborations and project contributions I’ve had in my decade-long career in tech.
MCP, by virtue of its sheer gravitational pull, brought together a massively talented group of people in record time. I’ve never seen anything like this. As I look forward to 2026 and all the MCP things we’ll be building then, I am sure that we’re in for some exciting new developments. And as a neat bonus, I get to spend more time with these folks!
I am also excited to see the adoption and volume of MCP servers grow - we’re at 2,728 indexed MCP servers at the time of me writing this blog post.
One goal that I set for myself for this year is to speak more in public about the projects that I work on. I wanted to join at least two events. Yep, just two - start small. I think I ended up blowing past that by a good margin.
I had a talk at MCP Dev Summit, I presented at Build with James Montemagno and with Amanda Silver, talked about MCP at AI Engineer World’s Fair, gave a couple of talks at Visual Studio Live, went on stage twice at GitHub Universe, was part of MCP Dev Days, joined James Montemagno again for AI Dev Days, gave a talk at MCP Night 3.0, and had to decline a few other opportunities that I couldn’t quite squeeze into my schedule (my apologies if you are one of the organizers - let’s try again next year).
That’s aside from a bunch of YouTube presentations I had the privilege of joining, along with a short interview with folks at The Pragmatic Engineer. Not too shabby for a small aspirational goal.
Earlier this year, I had a somewhat serendipitous change of responsibilities - I went from working in security and authentication/authorization SDKs to working on AI (it’s no longer the Developer Division - just CoreAI). Albeit unplanned, that was a change that opened so many doors for me (hello again, MCP).
This change reinforced my belief that the more often I push myself out of the comfort zone, the better. And you know what, any large-scale change may seem scary in the moment but in retrospect it is the right thing to do.
Through my career, I’ve had several of these moments - quitting Microsoft to join Amazon (although arguably that’s a low-risk jump), going to a startup during the pandemic, and then coming back to Microsoft right as hiring was slowing down.
The change from security to AI was a bit uncomfortable, but nothing like rolling up your sleeves and jumping in to get rid of any remaining jitters. That bet paid off handsomely.
You know how you can do everything for a viral hit and then get crickets? But then sometimes you have a little experiment that you want to get some community feedback on because you don’t want to incubate it internally for too long, and it absolutely destroys your expectations? You know, kind of like my “Seinfeld in Tech” memes?
As it turns out, this year I had an unexpected hit on my team’s hands - GitHub Spec Kit. When John Lam and I launched this project in August, our intent was very much not to create the next big trend in AI-based software engineering. And yet, here we are.
And I know that I will be talking about vanity metrics, but the number of stars acquired per day for that project is still staggering to me, even if it slowed down a bit since launch.
If you prefer to look at repository stars in aggregate, here is what it looks like, all in less than four months:
GitHub Spec Kit also is now the second most starred repository in the entire GitHub organization. Breaking all sorts of internal records with a little “Wonder what would happen?” project.
Aside from the unexpected success of GitHub Spec Kit and the myriad of videos I created for it (you can read about it on the GitHub blog or the Microsoft blog, whichever you prefer), I also:
My podcast, The Work Item, despite being on the backburner in 2025 because of other higher-priority projects still pushed me to release a few excellent episodes. I have bigger plans for it in the coming year.
Despite the busyness with the day-to-day, I very much tried to keep my hands on the keyboard as much as possible - the stuff that I am building is not just about material for blog posts. I find it super important to carve out time to try out new tech, experiment with different programming languages, and feed my curiosity by continuously finding new things to reverse engineer.
I always had this idea in the back of my mind that the best lessons come from either direct experience or someone that is believable and can explain their takeaways in the shape of a reusable framework. An epiphany I had recently, however, is that sometimes this model doesn’t fit the cases where important lessons are gifted to us from some of the sources we least expect, unbeknownst to us until much, much later.
This year, I learned to recognize the growing importance of endless curiosity, unconditional courage, and unshakeable resilience.
Curiosity to me is all about the acknowledgement that there is a lot more out there that I simply don’t know about, but it’s totally within reach if only I get out of my comfort zone. And by the way, it’s not about just tech stuff, which is easy to zero in on as someone that works in the field. It’s about the environment and opportunities around us. People’s perspectives, places, food, hiking paths, books, movies, games, and so much more. Living life in a perpetual comfort zone, within the same constant routine, is not what this is all about.
Courage boils down to doing the right thing and standing up for what is right. This is not always the easy choice, but it’s a choice that must be made to push boundaries. Don’t be afraid to take that next career step you’ve been mulling over. Don’t hesitate to join your friend on an adventure building something because the outcome is not yet known. Don’t sit silent when you see someone bullied or talked down upon. The first step is scarier than the actual possible outcome.
Lastly, resilience to me is about being able to withstand the absolute deluge of unexpected curveballs with grace. This is not about avoiding struggle or pretending that struggle doesn’t exist. For what it’s worth, we all have our moments, but giving up is just not an option for me.
I am looking back at this past year with an enormous amount of gratitude. The opportunities and projects that came my way did so because at some point, someone put their trust in me, and I am incredibly thankful for that. The more time goes on, the more I recognize that it’s always, always about people. Tech changes, trends come and go, but you’d be surprised by just how often you’re going to cross paths with people you worked with a decade ago.
2026 is around the corner, and I am positive it will carry its own bucket of changes and unexpected detours, but that’s to be expected, right? Here are a few things that I look forward to:
And, as my favorite piece of swag from Anthropic says, keep thinking.
May 2026 bring you nothing but all of the best from your list of aspirations!
2025-12-03 08:00:00
This year I wanted to be a bit more intentional with spending time reading. Given the day-to-day busyness (day job, MCP community work, and other adventures), I especially felt like I was losing the opportunity to immerse myself in new titles outside my regular list.
To encourage myself, I even went as far as creating a proper book tracker on this very website. This work was heavily inspired by the effort that Molly White put into her reading list (with a monthly review entry to boot).
All of this being said, November has been a bit sparse in terms of books I picked up, but the ones I did were phenomenal.
| Author | Simon Jimenez |
| Rating | ★ ★ ★ ★ ★ 5/5 |
| Link | Buy |
I picked this book up from the library because it was part of a Book Bingo category - Found Family. Its events take place in the distant future, where space travel is ubiquitous, but with its quirks. A mega-corporation owns the bulk of the inhabited planets, with some worlds from the galaxy-wide colonies being designated as “resource worlds,” their sole purpose being the production of resources for the mega-corporation.
As part of the process of collecting resources from these “resource worlds,” a scrappy crew of traders travels back and forth between planets, with the caveat that doing so requires breaking the rules of time and space - they have to fold through a pocket, where the trading crew only spends months, but on the planets they visit years go by.
The novel is written from several perspectives that shift through the narrative. It starts with one of the inhabitants of the resource planets, who describes the cyclical process of traders coming every fifteen years, collecting the resources, and then flying away.
The second perspective is introduced through the eyes of a captain of one of the trader ships - Nia. Nia had a rough upbringing but finds solace in being around a ragtag crew of shipmates that help her transport the goods over months traveling through space. At some point, a pod crashes on the aforementioned “resource world,” with a boy who did not speak or provide any clues as to where he came from.
As Nia was departing with her trading crew, she picked the boy up with her on the ship, determined to bring it back to one of the corporate-owned space stations, where he can be cared for.
Then, another perspective is introduced - that of Fumiko Nakajima, a remarkable scientist who designed the interplanetary space stations. Fumiko was a genetically-engineered child who was intentionally created in, what is known as a “post-vanity” world, with pre-designed physical appearance deformities. Through her university work, she meets Dana - a researcher working on eco-friendly tech, solar panel fields, and bio-farms. Notably, Dana is the opposite of Fumiko when it comes to appearance:
She was the tallest woman in the room by a head. Her hair was cut short, with blond Nero bangs that fell evenly across her brow. Her ears were sylvan, pointed at the tip, and her lips full and red, without makeup. On her cheek were five freckles, each freckle a point of some invisible star, just below her right eye; an eye that was large, luminous, its iris purple and flecked with gold, which reflected nothing but Fumiko’s post-vanity face.
Fumiko and Dana fall in love and spend as much time as possible together, especially given that they are living through a critical juncture in Earth’s lifecycle, a time when climate change kicked off irreversible processes - cataclysmic weather events and massive population displacement.
This is where the story takes a bit of a dark turn. Fumiko signed a contract with the mega-corporation to design the space stations that can help evacuate parts of humanity and preserve life away from Earth. This would require her to be isolated for several years with no contact with the outside world, including from Dana (with the exception of the occasional letters). By the time Fumiko is done, Dana moved on and met someone else. She was in the middle of all the civil unrest and chaos occurring in her parts of the world, with no help from Fumiko.
In the meantime, Fumiko became famous - after all, she was the scientist that designed humanity’s salvation. She is spending a good part of her time in cryogenic sleep to prolong her life, with the occasional appearance on stations that she created. She never lives down her missed opportunity with Dana, always having assistants around her that were artificially made to look like Dana in physical appearance (including doing things like coloring their eyes purple).
Fumiko catches wind of the boy on the trade ship and is convinced that he has a secret talent that is bound to revolutionize space travel. That talent is teleportation - the book spends some time setting this up, but ultimately the goal is to reverse-engineer the boy’s ability (if he has it) and then use it for the benefit of the corporation.
It’s also worth mentioning that the corporation this all occurs under the umbrella of is very particular about protecting their intellectual property, at often high cost to those that violate their rules. Fumiko will actually be on the receiving end of their wrath down the line.
Fumiko hires Nia’s trade ship to go and hang out on the outskirts of the galaxy for many years to wait for the boy to develop his abilities (again, if they even exist - nobody is sure of that yet). Through that journey and many stops of the trade crew, the boy eventually discovers his own ability to navigate between places quickly and effortlessly. He learns the quirks of the process and how to manage it, but as he did that, one of the shipmates finds the talent out and informs Fumiko, and by proxy - the corporation about the newly-found ability (said shipmate was in charge of documenting the process to begin with).
While all of this is occurring, Fumiko is working on a remote research station with her own team. The pace of the entire novel picks up right then and there - the corporation found out that Fumiko attempted to effectively hide the discovery from them, and is punishing her in the most cruel way imaginable, leaving her stranded with nutrition supplies but no tools or any other people around her - all alone, with no chance of escape.
In the meantime, Nia’s ship is assaulted by the corporation to extract the boy, thanks to someone within the crew who betrayed the crew’s trust. As the boy is kidnapped, he is then instantly handed off to the team responsible for figuring out how his talent works. Ultimately, they do - the boy is now effectively locked in a pod, with his blood being the driver for a corporation-produced teleportation engine. He is relegated to being merely a vessel to be extracted from - hooked to all sorts of wires to IVs, stranded in a corporate-owned corner of the galaxy.
Meanwhile, both in separate parts of the world, Fumiko and Nia are desperately planning how to recover the boy - each in their own way. Fumiko eventually finds a way to leave the station (in an extremely unexpected format, at that), and Nia connects telepathically with the boy through an artifact that was always with him from the day he crashed on the “resource world.”
I won’t spoil the ending, but this space opera was definitely not what I expected it to be - in a good way! The start of the book was a bit slow and maybe even confusing, but halfway through I could not put it down.
| Author | Allison King |
| Rating | ★ ★ ★ ★ ★ 5/5 |
| Link | Buy |
Also an unexpected gem for the Book Bingo from our local library - I picked it because it was fitting the Flowers On Cover category, and wow - what a story.
The entire book is written mostly from two diary perspectives - that of Wong Yun and Monica Tsai. Monica is a computer science student and Yun is her grandmother. The story is structured as “timeline snapshots” - Yun is documenting her life in pre-war Shanghai, her family, and the struggles they encountered through World War II, the Chinese Civil War, uprooting part of her family and moving to Taiwan, and subsequently settling in the United States.
Monica, on the other hand, is documenting her work on a college project, called EMBRS, designed to capture journal entries and personal information (such as social media) and then make connections with people based on that information. Through EMBRS, Monica discovers her grandmother’s cousin, Meng, with some extra help from another college student who happened to be in Shanghai at that time - Louise.
Through Louise, Meng sent Yun a pencil - a seemingly insignificant gift, that then unravels a number of stories on Yun and Meng’s background. As it turns out, the women in Yun and Meng’s family line have the ability to “melt” the pencil heart into their blood and re-live and re-create the writing and memories crafted by the pencil owner with that pencil. This is what’s known as “reforging.” With this story piece in place, the entire interwoven narrative becomes that much more complex - in Yun’s youth, just like her mother, aunt, and cousin, she was roped into a number of intelligence-related tasks, helping smuggle messages through pencils. After all, the pencil owners could write anything, discard the writing, and then transfer the pencil to someone who can reforge it to get the message.
Monica and Louise, in the current day, develop their own relationship - one that initially is based on Louise’s hidden desire to document and archive Monica’s grandmother’s stories, but going way beyond that as they get to know each other. Their relationship then gets contrasted to that of Yun and her cousin as well as Yun and her husband, who she met in Taiwan but didn’t marry until much later, when she moved to the United States.
This book was, hands down, the highlight of this month’s reading list. The story is captivating and as you progress through the historically detached diary entries - it starts making more and more sense and the big scattered puzzle suddenly starts making sense. This book has everything - spy intrigue, romance, adventure, and plenty of reflections on privacy and the value of stories in life.
